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in this issue ... 


Welcome to a new year of ;login:. You 
may notice that with this issue the 
internal order has changed a bit: 
USENIX News has moved from the 
front to the back. This decision was 
based on the realities of print 
production. News items tend to be the 
last material to come together, and you 
can't lay out the rest of a magazine if 
the first section isn't ready! Don’t miss important information in this issue's 
News section about the 1998 election for the USENIX Board of Directors. 

A “dose of reality” is prevalent in this issue - editor Rob Kolstad resolves in his “motd” 
to make sure that his business contacts are “dealing with reality and not promises, 
hopes, or dreams.” Other authors seem to have picked up the theme and want to share 
with you their recommendations for grounding decisions and behavior in the concrete. 
(Of course, practical features, such as “Using Java,” “ToolMan,” and “Using C++ as a 
Better C,” are ;login: s stock in trade.) Neil Gunther, continuing his series of articles 
comparing UNIX and NT scalability, explains how misuse of a benchmarking technique 
can distort reality. In the SAGE section, Phil Cox points out that without good system 
auditing, the chances of discovering what actually has happened in a security incident 
are nil, and he provides excellent guidance on how to begin auditing. And John Sellens 
discusses how system administrators can act more reliably by considering one of the 
most important realities of their environment - the people they work with. 

This issue also features an enjoyable interview with Bill Cheswick and reports from two 
USENIX conferences held in October 1997. Andrew J. Forrest has provided thorough 
and informative summaries of the sessions at the Conference on Domain-Specific 
Languages, and several attendees have contributed reports on LISA ’97. We hope you'll 
like the photo portion of the LISA reports too. 

Finally, we’re proud to include a news article about the generous level of support 
USENIX provides for a variety of worthwhile causes. Find out how your Association 
makes a difference “out there.” 
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letters to the editor 


Two Letters in Response 
to Lee Damon 

[WWWhither(ing) Internet , 

December, 1997] 

Speaking as one of those ex-ARPA 
research contract guys you applaud, let 
me say that I couldn't disagree with you 
more. One of the whole reasons we 
worked on the project was to incremen¬ 
tally add accessibility. In the beginning, 
that was limited to new TIP and TAC 
nodes, then to variant hosts, then various 
byte and word order weirdnesses, then to 
encapsulated protocols. The point was to 
increase access, and not just for so-called 
“serious research,” but for contractors, 
the military, then for schools, etc. 
Although no one ever talked about a 
node in every home, that was a failure to 
project on our part, not something out¬ 
side the envelope. 

The access you complain about sounds 
an awful lot like the complaining that 
occurred every time a new load of the 
clueless crowd hit the nets over the last 
ten years. One surprising thing about 
those folks ... they all eventually either 
got a clue, or they gave up and went 
away. Every time one of them went away, 
it was not a success for technical 
Darwinism, but instead a failure of the 
interfaces and protocols we had built to 
support them. 

So what if the current users tend to view 
the Web as the whole net? In terms of 
greatest utility, they're right. We're suffer¬ 
ing under a USENET not built to scale 
well, hideous old protocol interfaces, and 
a software/interface elitism that would 
stun a hieratic priest. 

Your more serious charge is that users 
will not find sufficient utility and value in 
the Web to justify an ongoing dollar out¬ 
lay and time commitment to use it. I 
hope you're wrong. There's not a lot of 
data out there right now, but the survey 
data I have seen tend to show that a large 
cross-section of net users tend to find 


continuing value, and that although there 
is a drop-off in use, it's not nearly as 
steep as the drop-off in other acquired 
skills, like bowling or scuba diving. 

To hope that the masses will find so little 
value in a technology that promises egali¬ 
tarian access to an unprecedented depth 
of knowledge, history, scholarship, and 
entertainment that they'll drop it and go 
back to watching TV is horrendous, and 
you ought to be ashamed of yourself for 
such blatant technoclassism. 

For those of us that embrace this change 
in our user community, the mission 
should, by now, be clear. It's our job to 
make it easier and better, not harder. If 
people think that the Web is the Internet, 
then it's our job to make all those 
resources available through the Web or 
Web-like interfaces. If the accepted navi¬ 
gation tool proves to be a thin client with 
a remote control, then it's our job to 
understand that and take it into account 
when designing resources, not to put up a 
“come back when you have a clue” sign 
and hide in net nostalgia. 

It's my personal hope that Joe Six-Pack 
and his kind will find themselves drawn 
into a new world of access and resources, 
not to drive them away. Who knows, 
some Joe Six-Pack might just be another 
Rembrandt or even a Lee Damon, just 
waiting to get turned on to what's possi¬ 
ble out there. Your approach is a sure 
method to save the technopriesthood, but 
isn’t it possible that it's time for that par¬ 
ticular religion to fade away? 

Greg Maples 
<greg@clari.net> 


I won’t even try to argue that the Internet 
is currently caught up in a flurry of 
media hype even worse than Clear Pepsi, 
and we all know how well that went, but 
to suggest that the Internet is “the fad of 
the decade,” similar to the “CB radio in 
the 70s” and destined to “collapse under 
its own weight” is just as myopic as the 
vision of the supposed neophytes to the 
Internet who believe that the Web is All 
There Is. 

As a result of all this hype, much of the 
image that the general public has of the 
Internet can be broken down into four 
basic types. First, “The Internet is a smut- 
ridden cesspool of filth, populated entire¬ 
ly by furry-fisted geeks.” While it is true 
that a large portion of what we see on the 
search engines is from the e-sex industry, 
it is not the majority, just the most visible 
and most easily criticized. Furthermore, 
the e-sex community has brought about 
as many, if not more, advances in the 
realm of online commerce than any other 
institution, so their presence, however 
seedy, has benefited the business commu¬ 
nity as a whole. 

Second, “The Internet is merely a fad, 
destined to go the way of the hula hoop.” 
This view comes mainly from those who 
have little actual experience with the 
technology. Anyone who had spent even a 
small amount of time looking at the his¬ 
tory of the Internet would know that 
above and beyond the thousands logging 
in daily for the first time, there are tens of 
thousands of us who have been in that 
quaint small town for several years. I have 
been a quiet resident for over four years 
now, and I know that there are others 
who have been there even longer. How 
often do you get to meet the founders of 
a “small town” of twenty million people? 
Not very often, and on the Internet, 
many of them will actually stop and chat. 
With the sheer numbers alone, the 
Internet has surpassed any of the fads 
listed without even mentioning the die¬ 
hard core who were proselytizing of this 
land of milk and honey years ago. 


jf 
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more letters ... 


Third, “The Internet contains only fluff.” 
This one, I can speak to personally. I have 
personally located pages upon pages of 
information that would not have been 
available to me through other means, 
including research on my favorite author 
(Bruce Chatwin), a relatively unknown 
classical composer named Pavel Haas 
whose brilliant career was cut short by 
the senseless Nazi slaughter, the friend¬ 
ship, support, and knowledge that has 
helped me keep my marriage together, 
and countless pages of information on 
health issues. The fact that the Internet 
provides access to everyone to publish 
their thoughts is NOT a detriment! The 
ease at which individuals can publish 
their information, no matter how seem¬ 
ingly trivial, focused, weird, or pointless, 
gives us access to a body of knowledge 
greater than any physical library in 
history. 

Finally, and most annoying to me, “The 
Internet was great in the good old days, 
but all these idiot newbies have ruined 
it.” It is in this statement that the Internet 
shows its academic roots. Despite what 
I’ve said, there are those who have been 
in my town for many years, those whose 
heads are so filled with the grandeur of 
their private empire and the glories of 
their teaspoon Gardens of Eden that they 
have collapsed into the same xenophobia 
and isolationism that plagues many 
rapidly growing communities. To this 
small group, the media spotlight is a 
menace because with it comes “Them,” 
that nameless mass against whom all of 
us have fought at one point or another, 
without realizing that without Them, the 
Internet wouldn’t have nearly the 
resources, vibrancy, or diversity that it 
has today, or, more importantly, that we 
in that small 


town of the Internet have been viewed as 
Them by those we wish to keep out. 

As frightening as it seems, the broad 
acceptance of the Internet means an 
acceptance, and eventually demystifica¬ 
tion, of our trade. For many, many years, 
we have been viewed in both the eyes of 
the world and of ourselves as wizards, 
possessors of arcane knowledge too 
strange, too difficult to be grasped by 
mere mortals. With every newbie, with 
each coin in AOL’s cup, another person 
becomes a part of that inner circle and 
our power is that much more dimin¬ 
ished. It’s no wonder that Lee of the 
Arcane Hat hopes for the Internet to “col¬ 
lapse under its own weight” and become 
once again “the domain of old timers and 
the few clued individuals who have dis¬ 
covered that the Internet is much more 
that just a Web and some Usenet posts.” I, 
for one, hope that never happens. 

Jon Williams 
<dragon@revealed.net> 

Erratum 

Not sure if I should be sending this to 
you guys, but what the heck .... 

There is an incorrect reference on page 
57 of the special ;login: issue on Windows 
NT [November 1997], though I am not 
sure if the error is in the report or in 
what was presented. 

The summary of Michael Frederick’s 
“Utilizing Low-Level NTFS Disk 
Structures for Rapid Disk Searching” talk 
lists two references, but the first reference 
is incorrect. The reference should be 
“Inside the Windows NT File System,” 
not “Inside Windows NT,” both of which 
were written by Helen Custer. 

Though the book is pretty good, as some¬ 
one who has been trying to use a file sys¬ 
tem book as a guide to implement NTFS 
under NetBSD, I think it is missing a bit 
more than just “the numbers.” 

Alan Perry 

<alanp@phcnet.com> 


Rik Farrow responds: 

The fault was mine. I was unaware of the 
NT filesystem book and had the title 
changed to the book I knew that Helen 
Custer had written. 

Mea culpa. 

To: Rik Farrow 

I enjoyed reading Musings in the 
December ’97 ;login: but would like to 
make one correction. 

When IBM released the first PC in an 
uncharacteristic spirit of openness, it 
published the PC Technical Reference 
which provided all the hardware specifi¬ 
cations and a BIOS listing. There was no 
need to reverse engineer the BIOS but 
numerous copyright lawsuits were filed 
or threatened against BIOS doners. 
Phoenix, AMI and others bypassed copy¬ 
right infringement by sprinkling NOPs 
throughout their firmware. 

I’m writing this just after Microsoft lost 
the Internet Explorer anti-trust case. 
Another case of boundaries is Microsoft’s 
insistence that all PCs sold contain a copy 
of one of their operating systems leaving 
the customer with no choice in the 
matter. 

Mick Carberry 

<carberrm@toronto.cbc.ca> 

Rik Farrow responds: 

Thanks for your comments on the 
December Musings. I really did believe that 
the code was reverse engineered on a func¬ 
tionality basis using a clean room 
approach, not simply copied with NOPs 
added. In my own experience with copy¬ 
right law (as a writer, not a programmer) 
only 10% of the original material can 
remain or the copyright has been violated. 
You then appear to be suggesting that 91% 
of the Phoenix BIOS was NOPs. NOPs are 
fast, but.... 
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Conference on 

Domain-Specific 

Languages 

SANTA BARBARA, CA 


October 15-17,1997 


Summaries by Andrew J. Forrest 

OVERVIEW 

USENIX held its first ever conference 
on the subject of Domain-Specific 
Languages (DSLs). The purpose of the 
conference was to bring together people 
who are interested in the idea that pro¬ 
gramming languages are first-class tools 
to exploit in the creation of software, and 
that the development of problem-appro¬ 
priate computer languages is the basis 
for a valuable approach to software 
engineering. 

Although this conference was organized 
into seven sessions, each with a specific 
focus, a number of themes emerged, cut¬ 
ting across sessions and recurring in 
many presentations. 

Domain-Specific Languages - 
The Ultimate Abstraction 

This theme holds that Domain-Specific 
Languages represent direct support for 
key abstractions in a programming 
domain. A DSL can represent an abstrac¬ 
tion in a way that offers advantages when 
compared with other abstraction 
approaches, such as the use of libraries. 

Language as a First-Class Tool 

This theme presents language as a funda¬ 
mental tool; it revolves around the idea 
that in many circumstances it is appro¬ 
priate to create a new language rather 
than rely on the less specialized features 
of an existing general-purpose program¬ 
ming language. 

Domain Analysis and Design for DSLs 

A key step in the creation of a DSL, 
domain analysis is done to varying 
degrees of formality. The main question 


is “How does one pick the appropriate 
abstractions for the DSL to contain?” Is 
there a process for this? What is the rela¬ 
tionship between the language designer 
and the domain expert(s)? Does the 
domain already have an accepted nota¬ 
tion that suggests itself as a syntax for the 
DSL? 

DSL Implementation Framework 

This theme examines the various means 
by which a DSL can be implemented. 
Should a DSL be embedded in a larger, 
more general-purpose language (GPL)? 
Should it be implemented via a pre¬ 
processor? Or should an entirely separate 
implementation be developed? 

DSLs and Rapid Prototyping 

This theme occurs in two forms: DSLs 
support rapid prototyping because they 
tend to operate at a high level of abstrac¬ 
tion; and rapid prototyping supports 
DSL creation by facilitating iterative 
design of the language. 

Compiler Support and Tools for DSLs 

Because DSLs are created more frequent¬ 
ly than full GPLs, and because they may 
be changed more frequently, the need for 
compiler-compiler and other translator 
tools is greater with DSLs than with 
GPLs. It seems that the needs of DSL cre¬ 
ators could influence compiler construc¬ 
tion technology toward such benefits as 
more debugging, better debugging, sup¬ 
port for specifying semantics, and more 
visualization. 

Advantages of DSLs 

Finally, there are many, many advantages 
to DSLs, such as notational convenience, 
certain type checking and global opti¬ 
mization opportunities, the ability to 
make additional safety guarantees, the 
potential for domain experts to program, 
the possibility of a variety of analysis, and 
the ability to capture an abstraction, 
thereby serving as an example of reuse. 

Regarding the conference as a whole: a 
very high proportion of attendees was 


This issue's reports focus on the 
Conference on Domain Specific 
Languages, held in Santa Barbara, 
CA, on October 15-17, 1997, and on 
the 11th Systems Administration 
Conference (LISA ’97), held in San 
Diego, CA, on October 26-31, 1997. 


Our thanks to the Summarizers: 



<forrest@research.att.com> 


<rgcg@colltech.com> 

CmojynM. Hennings. 

cmh@colltech.com 

<Brad.Johnson@SystemExperts.com> 

<mkm@mellis.com> 


<Wei@colltech.com> 

<wynn@colltech.com> 
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present for the entire conference despite 
the pleasant weather and beachfront 
venue. Interest in the BOFs was so great 
that initial plans to run them concurrent¬ 
ly were shelved in favor of a consecutive 
schedule, and the papers presented were 
of such uniformly high quality that the 
program committee was unable to single 
out one for special commendation! 
Overall, I believe the conference was a 
great success and would not be at all sur¬ 
prised if USENIX were to repeat it at 
some point in the future. See you there! 

KEYNOTE ADDRESS 

The Promise of Domain-Specific 
Languages 

Paul Hudak, Yale University 
Department of Computer Science 

Domain-Specific Languages: 

Some Definitions 

With help from a motley crew of animat¬ 
ed agents residing in his laptop computer, 
Paul Hudak began his entertaining and 
thoughtful keynote address on the 
promise of Domain-Specific Languages. 
Hudak offered a framework for thinking 
about and working with DSLs, starting 
with a definition of the term itself: “A 
programming language tailored specifi¬ 
cally for an application domain: it is not 
general purpose but rather captures pre¬ 
cisely the semantics of the domain, no 
more and no less.” He quickly followed 
with a definition of “application 
domain,” which he accomplished by way 
of example, citing simulation, lexing and 
parsing, CAD/CAM, hardware descrip¬ 
tion, text/pattern matching, computer 
music, and database queries, among oth¬ 
ers. To add to the list, Hudak said, one 
merely needs to reflect on the question: 
“How many papers have you seen with a 
title such as XXX: A Language for YYY?” 

Hudak also offered a second definition of 
a DSL: “the ultimate abstraction of an 
application domain; a language that you 
can teach to the intended user in less 
than a day.” This definition relies on the 


observation that the intended user of a 
DSL is probably already well versed in the 
semantics of its domain and needs only a 
suitable notation with which to program. 

In case you think DSLs are something 
new, you could ponder the list of popular 
and successful DSLs and their domains 
that Hudak presented: 

■ Lex and Yacc (for program lexing and 
parsing) 

■ Perl (for text/file manipulation/script¬ 
ing) 

■ VHDL (for hardware description) 

■ TeX and LaTex (for document layout) 

■ HTML/SGML (for document markup) 

■ Postscript (for low-level graphics) 

■ Open GL (for high-level 3D graphics) 

■ Tcl/Tk (for GUI scripting) 

■ Macromedia Director (for multimedia 
design) 

■ Prolog (for logic) 

■ Mathematica/Maple (for symbolic 
computation) 

■ AutoLisp/AutoCAD (for CAD) 

■ emacs Lisp (for editing) 

■ Excel Macro Language (for things 
never intended) 

Advantages and Disadvantages 
of the DSL Approach 

Chief among the advantages of the DSL 
approach to software development is 
higher programmer productivity because 
programs written in a DSL tend to be 
more concise, quicker to write and main¬ 
tain, as well as easier to (automatically) 
reason about. Furthermore, although it 
sounds oxymoronic, DSL programs can 
sometimes be written by nonprogram¬ 
mers. Hudak observed that these motiva¬ 
tors are the very ones that drove the 
adoption of high-level general-purpose 
languages in the first place! 

Of course, the DSL approach is not with¬ 
out challenges, too: performance may be 


poor because high-level languages are 
sometimes inefficient; there may be unac¬ 
ceptable start-up costs associated with 
the development of a DSL; a “Tower of 
Babel” may result if every domain 
acquires a specific language; the tempta¬ 
tion to add features incrementally to a 
DSL can lead to bloat; and perhaps most 
important, designing and implementing 
languages (well) is a very hard task typi¬ 
cally requiring two to five years for a new 
one. All of these issues represent possible 
obstacles that we need to overcome in 
order to more readily enjoy the benefits 
of DSLs. 

A Recommended Approach 
to DSL Development 

Given his experience with implementing 
and using a number of DSLs, Hudak dis¬ 
tilled these recommendations for build¬ 
ing software with a DSL: 

■ Choose your domain. 

■ Design a DSL that accurately and effec¬ 
tively captures the domain semantics. 
Concentrate on the semantics. Don’t 
let performance dominate design. Try 
to keep the end-user in mind at all 
times and to keep things as simple as 
possible. 

■ Prototype your design; refine and iter¬ 
ate. Also build SW tools to support the 
DSL. 

■ Develop applications (domain 
instances) using the DSL infrastruc¬ 
ture. 

■ Success equals a happy customer! 

Hudak observed that, although syntax 
and semantics are well treated in current 
and prior DSL development, tools often 
receive short shrift. 

The Embedded DSL: 

An Implementation Approach 

To overcome the weakness in tool sup¬ 
port and to address some of the earlier 
noted disadvantages, Hudak advocated an 
approach to DSL development whereby 
the DSL is embedded in an existing, more 
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general-purpose programming language 
- an Embedded DSL or “DSEL.” A DSEL 
inherits general-purpose features from 
the enclosing language, the “host,” as well 
as that language’s existing tool set as a 
base. This frees the DSL designer who is 
implementing the DSL to concentrate on 
semantic issues and then provide 
domain-specific optimizations and exten¬ 
sions for an existing tool set. Hudak also 
advocated the use of metaprogramming 
tools such as transformation systems or 
partial evaluators to recover performance 
and practicality that might otherwise be 
sacrificed by the embedded approach. 

As advantages of the DSEL approach, 
Hudak cited rapid DSL design, increased 
changeability, familiar look and feel, 
reuse of infrastructure, a reduction in 
language bloat, and because whatever 
formal methods are applicable to the host 
language are applicable to the DSL, the 
possibility of using algebraic/denotation- 
al semantics. 

A DSL tends to share the same limits and 
face the same problems as the underlying 
host language, so Hudak cautioned that 
the choice of host language should be 
made after the abstract design of the DSL 
so that it can be made based primarily (if 
not entirely) on its suitability for hosting 
the particular DSL rather than on some 
other considerations. 

The Lightweight DSL: 

An Implementation Refinement 

Hudak introduced a refinement to the 
embedding approach called the 
Lightweight DSEL, which is a “pure” 
embedding. He noted that this approach 
requires a fairly powerful base language, 
one with higher-order functions, auto¬ 
matic memory management, syntactic 
extensions, flexible evaluation, and a flex¬ 
ible type system. In fact, in his experience 
implementing DSLs in Haskell, Hudak 
has made significant use of the higher- 
order functions, lazy evaluation, type 
classes, monads, and infix syntax features 
of Haskell. According to Hudak, the 


definitive way to embed a DSL within 
Haskell is to treat the DSL as an abstract 
data type for which an implicit inter¬ 
preter represents the semantics. In this 
way, equational reasoning can be used to 
verify key algebraic properties of the 
DSL. 

Conclusion 

Hudak concluded by saying that DSLs are 
a good thing. Embedded DSLs and light¬ 
weight DSELs can be good things, but we 
need more and better tools to help with 
the design and implementation of DSLs. 
He also said that there should be a shift 
in emphasis in tool design from syntax to 
semantics, that the science of computer 
science has a role to play here. 
Algebraic/denotational semantics, modu¬ 
lar interpreters, modular program execu¬ 
tion tools, extensible type systems, and 
program transformation/partial evalua¬ 
tion were all mentioned as fruitful areas 
for this work. 

Hudak never explicitly addressed the 
teaser that introduced his abstract for the 
keynote address, namely, “Are domain- 
specific languages (DSLs) the long-await¬ 
ed silver bullet of software engineering?” 
However, he did argue cogently that DSLs 
have value and that embedding can be an 
excellent approach to the implementation 
of DSLs. In addition, he framed the entire 
conference with his definitions of a DSL 
and his worthwhile recommendations for 
the design and implementation of DSLs. 

To see more, consult his official and per¬ 
sonal home pages: 

<http://www.cs.yale.edu/HTML/YALE/CS/homepage 

/people/faculty.html\#hudak> 

<http://www.cs.yale.edu/HTML/YALE/CS/HyPlans 

/hudak-paul.html> 

<http://www.cs.yale.edu/HTML/YALE/CS/HyPlans 

/hudak-dir/dsl/index.htm>. 


REFEREED PAPERS 

Session: Domain-Specific 
Language Design 

Each of the three presenters in this ses¬ 
sion introduced a problem domain, char¬ 
acterized some of its unique aspects, and 
described the design goals of an appro¬ 
priate solution. In each case, the author 
showed how insight progressed to design 
and related the language design to the 
implementation architecture. 

Service Combinators for Web Computing 

Luca Cardelli, Digital Equipment 
Corporation, and Rowan Davies, 
Carnegie Mellon University 

Cardelli and Davies based this work on 
observations about both the unique char¬ 
acteristics of the World Wide Web and 
the way it is used. On the Web, docu¬ 
ments may be unavailable or slow to 
transfer. People compensate with inter¬ 
esting retrieval strategies involving multi¬ 
ple connections and preemptive behavior 
based on transfer rates. These strategies 
are not expressible via existing distrib¬ 
uted paradigms, such as remote proce¬ 
dure calls. Cardelli and Davies therefore 
began with the view that the Web is a 
new and peculiar kind of computer, the 
“Berners-Lee Machine,” and set out to 
derive a language for programming it. 

The result is a nascent language of service 
combinators for which a Java-based 
interpreter exists and a useful look at 
how one might go about designing a 
DSL. The language can be used to express 
typical human Web-browsing strategies 
because it allows direct references to the 
important characteristics of the Berners- 
Lee machine (including transfer rate). 

The authors offered a succinct formal 
semantics for the language and proved 
the correctness of certain optimizing 
transformations. This language of combi¬ 
nators was implemented as a set of com- 
posable Java functions rather than as a 
full-fledged language with its own unique 
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concrete syntax. The authors argued that 
this implementation approach can be a 
good prototyping technique because it 
provides a performance benefit, elimi¬ 
nates the possibility of parsing or lexing 
errors at runtime, and reuses the syntax 
of the host language and therefore the 
front end of that language’s compiler. As 
Davies noted, this is a general technique 
suitable for any Domain-Specific 
Language that is to be translated via an 
interpreter embedded in a larger (gener¬ 
al-purpose) language. 

<http://www.cs.cmu.edu/afs/cs.cmu.edu/user/rowan 

/www/home.html> 

<http://gatekeeper.dec.com/pub/DEC/SRC 

/research-reports/abstracts/src-rr-148.html> 

A Domain-Specific Language for Video 
Device Drivers: 

From Design to Implementation 

Scott Thibault, Renaud Marlet, and 
Charles Consel, IRISA/INRIA- 
Universite de Rennes 1 

In creating their DSL for implementing 
video device drivers, Thibault et al. 
undertook a formal domain analysis of a 
video device driver domain. As a result of 
this analysis, they adopted an architecture 
that combines a DSL, its interpreter, and 
an abstract machine in order to express 
and implement the video device drivers. 
The authors did not let performance con¬ 
cerns unduly influence their early design 
decisions and reclaimed the performance 
sacrificed by their architectural choice by 
using the technique of partial evaluation 
to curry the device driver program, its 
interpreter, and its abstract machine. 

<http://www.irisa.fr/compose> 

<http://www.irisa.fr/EXTERNE/projet/lande/consel 

/paper$.html#SE> 


Domain Specific Languages for ad hoc 
Distributed Applications 

Matthew Fuchs, Walt Disney 
Imagineering 

The final paper presented in the DSL 
Design session examined the value of 
DSLs as intermediate glue between dis¬ 
tributed “agents,” be they computational 
or human. Fuchs observed that humans 
find binary data inconvenient and that 
many ASCII formats prove tricky for pro¬ 
grams to parse. Yet distributed applica¬ 
tion components may need to interact 
with both software agents and human 
ones, and rather than construct each 
component with two interfaces, it would 
be nice to find a single format suitable 
for both. 

Fuchs recommended creating a DSL to 
subsume both of these interfaces - a sin¬ 
gle language for communicating state, 
behavior, and sequence to both human 
and computer-based agents. To represent 
the language, Fuchs advocated using 
SGML or its simplified subset, XML, 
because they are suitable for human use 
(they can be displayed by a graphical 
interface) and are easily processed by 
programs, especially in the latter case. To 
explore the value of this idea, Fuchs 
showed how the game of bridge can be 
represented by an XML object, which is 
passed from player to player during the 
course of a game. At each turn, the string 
is extended, with data representing a new 
bid or card play, and processed by an 
agent (human or computer) representing 
a player. 

Fuchs placed great value on the power of 
separating syntax and semantics in defin¬ 
ing a DSL. Interestingly, Fuchs also 
observed that LL(1) languages are partic¬ 
ularly well suited to use in this domain, 
especially for applications with a high 
degree of interactivity. This is because 
LL(1) languages permit top-down pars¬ 
ing, which means that a string in the 
language can be successfully parsed 


(i.e., the relevant production can be 
known) at any point during the string s 
construction. 

<http://cs.nyu.edu/phd_students/fuchs/> 

Session: Experience Reports 

Participants outlined their experiences 
with DSLs, what benefits they realized, 
what challenges they faced, and what 
advice they could offer to other potential 
DSL developers. 

Experience with a Domain Specific 
Language for Form-based Services 

David Atkins, Thomas Ball, Michael 
Benedikt, Glenn Bruns, Kenneth Cox, 
Peter Mataga, and Kenneth Rehor, 

Bell Laboratories, Lucent 
Technologies _ 

MAWL is a DSL for creating device-inde¬ 
pendent, form-based services. Such ser¬ 
vices are characterized by data flows 
between the service and its users in a 
series of query/response interactions. A 
form is the abstraction that describes 
each interaction between the user and the 
service. This simple but powerful abstrac¬ 
tion is the key to the numerous benefits 
provided by MAWL. Ball reported that 
MAWL enabled certain properties of a 
Web service to be verified at compile 
time, something that cannot be done in 
general for CGI scripts. Additionally, 
MAWL and its corresponding implemen¬ 
tation architecture permit certain flexibil¬ 
ities, such as the creation of a standalone 
service (independent of a Web server), 
the use of a variety of implementation 
languages, and even the substitution of 
different user interface devices. 
Furthermore, because a declaration of 
each form’s signature is available to the 
MAWL compiler, a functional Web-based 
stub can be generated automatically for 
the application, thereby permitting rapid 
evaluation of the service before extensive 
effort is invested in the various aspects of 
the eventual user interface. Because all of 
these benefits accrue directly or indirectly 
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from the central form concept, it seems 
safe to say that the experience with 
MAWL amply demonstrates Hudak’s sug¬ 
gestion that a DSL is the “ultimate 
abstraction” in a domain. 

<http://www.belNabs.com/projects/lVlAWL/> 

Experience with a Language for Writing 
Coherence Protocols 

Satish Chandra and James R. Larus, 
University of Wisconsin, Madison; 
Michael Dahl in, University of Texas, 
Austin; Bradley Richards, Vassar 
College; and Randolph Y. Wang and 
f Thomas E. Anderson, University of 
I California, Berkeley 

A veritable gold mine of concrete advice 
to DSL designers and implementers, this 
experience report described a language 
called “Teapot,” which is for writing the 
coherence protocols found in Distributed 
Shared Memory (DSM) systems. The goal 
of the language is to eliminate a variety 
of programming errors by providing a 
language that is specific (and restricted) 
to the applicable domain as well as to 
obtain both an implementation of a pro¬ 
tocol and a source for a protocol verifier 
from a single protocol description. 

This report offered many suggestions to 
prospective DSL designers: 

■ A DSL should probably be as small as 
you can stand. 

■ The language should directly support 
programming scenarios that occur 
commonly in the domain. 

■ A DSLs users should not need to know 
implementation details. 

■ Compiler optimizations should be 
explicitly specified and user-selectable. 

■ Provision of thread support should be 
considered from the outset. 

■ Be prepared to assist users in adopting 
your DSL; otherwise, natural inertia 
will preclude it (examples help greatly 
here). 


■ It is better to start with a small, focused 
DSL that satisfies a small user commu¬ 
nity and possibly extend it later rather 
than shoot for a rich language from the 
start. 

N It is important to be realistic and spe¬ 
cific about the capabilities and short¬ 
comings of your DSL (implementa¬ 
tion) when dealing with its user com¬ 
munity. 

Chandra et al.s report suggests that DSLs 
can be valuable, but that designing, 
implementing, and popularizing a DSL is 
not entirely straightforward. 

<http://www.cs.wisc.edu/~chandra/teapot/> 

Lightweight Languages as Software 
Engineering Tools 

Diomidis Spinellis, University of the 
Aegean, and V. Guruprasad, IBM T. J. 
Watson Research Center 

Guruprasad showcased various advan¬ 
tages, disadvantages, and implementation 
techniques germane to the DSL arena by 
presenting a survey of representative DSL 
systems covering user interface specifica¬ 
tion, the software development process, 
text processing, multiparadigm program¬ 
ming, and language implementation. The 
principal advantage cited in this work is 
that the DSL reduces the semantic gap 
between specification and implementa¬ 
tion, echoing once again the “ultimate 
abstraction” theme. 

Disadvantages do exist, however, and they 
include a tendency for the ad hoc nature 
of DSLs to contribute to a lack of suitably 
skilled personnel, training materials, and 
appropriate tools; doubts about scalabili¬ 
ty; and, through proliferation, a comput¬ 
er language “tower of babel.” Never¬ 
theless, the overall experience described 
by Guruprasad has been favorable. 


Implementation techniques were also dis¬ 
cussed, and implementers were encour¬ 
aged to (re)use existing source code and 
tools wherever possible, in the latter case, 
by combining language processors (i.e., 
generate a high-level language source). 
Simple syntax with lexical hints and self- 
documenting source files should all be 
used as well. Finally, features of the target 
and implementation languages may 
prove valuable to use. 


Session: Compiler 
Infrastructure for Domain- 
Specific Languages 


This session examined language tech¬ 
nologies that could provide benefits to 
DSL implementors. Two of the papers 
examined techniques that require open¬ 
ing up the language translator itself. 


A Slicing-Based Approach for Locating 
Type Errors 

T. B. Dinesh, CWI, and Frank Tip, 
IBM T. J. Watson Research Center 


The quality of tools that accompany a 
DSL can affect its success in being adopt¬ 
ed. One way to ease the creation of good 
and useful tools for DSLs is to generate 
them from specifications. Dinesh pre¬ 
sented work that describes a novel tech¬ 
nique for incorporating dynamic depen¬ 
dence tracking in an algebraically speci¬ 
fied type checker. While a programs 
abstract syntax tree is being rewritten 
into a list of type errors, a minimal por¬ 
tion of the source (a “slice”) is computed 
for each error. The slice has a special 
property: it is guaranteed to reproduce 
the original error. An entire slice is neces¬ 
sary because type errors are the result of 
source that is distributed throughout a 
program, unlike syntax errors, which can 
usually be localized to a single token. 

This work, called “CLaX,” has been 
implemented in the ASF+SDF Meta-envi¬ 
ronment for a substantial subset of 
Pascal. 

<http://www.cwi.nl/~dinesh/> 
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Typed Common Intermediate Format 

Zhong Shao, Yale University _ 

In order to facilitate both the ready gen¬ 
eration of compilers for DSLs and the 
interoperation of DSLs and general-pur¬ 
pose languages, a common substrate is 
required. FLINT, a typed intermediate 
format that satisfies this requirement, is 
discussed by Shao in this paper. 

Translator implementation is simplified 
by FLINT because a reusable “back end” 
is provided. Another benefit of FLINT is 
that it enables code written in multiple 
languages to interoperate. This is because 
each language’s translator can share the 
same back-end facilities (e.g., optimizers, 
verifiers, and generators) as well as run¬ 
time conventions (e.g., garbage collector, 
foreign function calling mechanisms). 
Finally, unlike other intermediate lan¬ 
guages, FLINT is capable of supporting 
higher-order languages such as ML. 

<http://flint.cs.yale.edu> 

<ftp://ftp.research.bell-labs.com/dist/smlnj> 

<http://www.cs.yale.edu/HTML/YALE/CS/HyPlans 

/shao-zhong.html> 

Incorporating Application Semantics 
and Control into Compilation 

Dawson R. Engler, MIT Laboratory for 
Computer Science _ 

What would happen if one stopped view¬ 
ing one’s compiler as a black box and 
opened it up, even just a little bit? What 
kinds of things could one do? Engler pro¬ 
vided one answer to these questions with 
a paper describing MAGIK, a system that 
permits users to hook into the compila¬ 
tion process and provide transformations 
or verifications that are driven by appli¬ 
cation semantics and yet still benefit 
from the optimization phase of the origi¬ 
nal compiler. Examples of the kinds of 
transformations and verifications possi¬ 
ble with MAGIK include verifying type 
safety between the format string and 
other arguments of the C language’s 
printf; determining if system call return 
codes are examined and, if not, adding 


code to do so; enforcing adherence to 
“programming rules” such as restrictions 
to be observed when coding UNIX signal 
handlers; and partial evaluation in the 
context of RPC parameter marshalling. 

<http://www.pdos.lcs.mit.edu/-engler/> 

Code Composition as an Implementation 
Language for Compilers 

James M. Stichnoth and Thomas 
Gross, Carnegie Mellon University 

Code composition is a technique that 
promises speedy implementation of com¬ 
pilers that are capable of translating high- 
level or complex operations with both 
good quality and efficiency. Catacomb 
performs code composition through the 
interaction of a composition system with 
a compiler. The compiler partitions the 
source program into two sets of con¬ 
structs, those for which code composition 
is offered and those for which it is not. 
For each construct that permits code 
composition, the compiler invokes the 
composition system. The composition 
system, in turn, processes code templates 
that are separate source-comprising code 
constructs and control constructs. The 
control constructs are “executed” by the 
composition system producing custom¬ 
generated code, which is then passed 
back to the compiler proper. Once under 
the compiler’s control, the custom-gener¬ 
ated code can be combined with the 
remaining code constructs and processed 
by all the further downstream processors 
(e.g., optimizers). 

Session: Logic and Semantics 
for Domain-Specific 
Languages 

This session focused on the role of math¬ 
ematical foundations in the creation of 
DSLs. The first two papers described 
valuable DSLs that have firm mathemati¬ 
cal foundations. The last paper described 
an advance in the specification of formal 
semantics. 


BDL: A Language to Control the Behavior 
of Concurrent Objects 

Frederic Bertrand and Michel 
Augeraud, Universite de La Rochelle 

This work was motivated by the observa¬ 
tion that managing concurrency in 
object-oriented systems is difficult. This 
is because, without language support, it is 
hard in general to ensure that program¬ 
mers manage to avoid such concurrent¬ 
programming pitfalls as failure to observe 
mutual exclusion protocols and dead¬ 
lock situations. The Behavioral 
Description Language (BDL) is a DSL 
that is used to specify and enforce various 
temporal constraints that may be placed 
on the use of one or more object’s inter¬ 
faces. BDL programs run on an execution 
controller that enforces the program’s 
specification. The mathematical founda¬ 
tion of BDL is the well-developed field of 
automata theory, which confers three 
principal advantages to BDL. Automata 
can be made to execute efficiently, many 
verification tools already exist for analyz¬ 
ing BDL programs, and an existing reac¬ 
tive programming language (in this case, 
Esterel) can be used to translate BDL into 
executable code. 

A Domain-Specific Language for Regular 
Sets of Strings and Trees 

Nils Klarlund, AT&T Labs Research, 
and Michael I. Schwartzbach, 
University of Aarhus 

Schwartzbach presented both FIDO, a 
high-level programming notation that 
concisely expresses regular sets of strings 
or trees, and a thorough analysis of the 
DSL experience as he and his colleagues 
see it. FIDO combines standard program¬ 
ming language concepts such as recursive 
data types, unification, implicit coer¬ 
cions, and subtyping with a variation of 
predicate logic called the Monadic 
Second-order Logic (M2L) on trees. M2L 
has proved very useful to Schwartzbach 
and his colleagues, but suffers from a 
tedious notation. FIDO corrects this. 
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Schwartzbach indicated that there is no 
substitute for domain experience in max¬ 
imizing the likelihood of creating a suc¬ 
cessful DSL. Often, such experience will 
expose a repetitive or error-prone soft¬ 
ware activity that must be performed 
when solving problems in the domain. 
Removing this repetitive activity from the 
programmer’s work and placing a solu¬ 
tion to it within a language is a key impe¬ 
tus for the creation of a DSL. 

Once a commitment to DSL creation is 
made, some reflection on the nature of 
the software problem and a domain 
analysis (formal or otherwise) takes 
place. The outcome of these steps is com¬ 
bined with a general knowledge of lan¬ 
guage concepts and language technology 
to create an implementation that, if 
everything goes well, provides relief from 
the original software problem. As with 
everything computational, some iteration 
may be necessary, in part because of 
imperfect execution of the earlier steps, 
but, surprisingly, also due to one more 
issue: the DSL’s implementation and its 
effect on your software problem may 
actually lead to further insight in the 
domain! It is this feedback that yields a 
deeper understanding of the domain 
that may, additionally, prompt another 
iteration in the cycle. 


A Modular Monadic Action Semantics 

Keith Wansbrough and John Hamer, 
University of Auckland 

If there had been an award for 
“Presentation with the Most Audience 
Participation,” Hamer certainly would 
have won it. After entertaining the audi¬ 
ence with an exercise in creating an 
origami frog, he presented some work 
done principally by Wansbrough on the 
fusing of Modular Monadic Semantics 
(MMS) with Action Semantics (AS) 
(yielding Modular Monadic Action 
Semantics). Action Semantics is popular 
for its highly readable notation, yet it is 
monolithic, supports only a fixed range 
of language concepts, and is somewhat 
difficult to employ in proving properties 
about a language or its programs. 
Modular Monadic Semantics is highly 
extensible due to excellent modularity 
and, because it is implemented in a func¬ 
tional programming language, its specifi¬ 
cations can be directly executed. Modular 
Monadic Semantics is considered to be at 
a slightly lower level of abstraction than 
Action Semantics and, unfortunately, is 
also considered to be a bit challenging to 
use. Modular Monadic Action Semantics 
thus combines the best aspects of Action 
Semantics and Modular Monadic 
Semantics to provide an extensible, easy- 
to-write notation. 


Evolution of a domain-specific language 



Session: Case Studies and 
Frameworks 

This session discussed work in interesting 
problem domains. In the first two papers, 
case studies of DSL creation and use were 
presented. The third paper documented a 
survey and analysis of Architecture 
Description Languages that could pro¬ 
vide the kind of domain understanding 
required for the creation of a new DSL. 

SHIFT and SMART-AHS: A Language for 
Hybrid System Engineering Modelling 
and Simulation 


Marco Antoniotti and Aleks Gollu, 
University of California, Berkeley 


The domain in which SHIFT operates is 
that of Hybrid Systems Analysis and 
Modelling which can be likened to simu¬ 
lation of situations where both continu¬ 
ous and discrete phenomena are present 
and interact. The SHIFT language con¬ 
tains terminology, notation, and seman¬ 
tics straight from the domain, making it 
readily usable by the intended audience: 
control system engineers. Befitting a case 
study, SHIFT has received significant use. 
This paper describes the reimplementa¬ 
tion of the Traffic Simulation framework, 
SMART-AHS, in SHIFT. Users reported a 
50% reduction in the size of both 
libraries and projects and greater ability 
to reuse code. Credit is given in the eval¬ 
uation of SHIFT to it containing the 
“right” abstractions, being somewhat 
restrictive compared to a GPL, and con¬ 
sequently requiring fewer “programming 
rules” than other systems. This last aspect 
is important because, as a DSL, SHIFT 
can enforce programming rules, so they 
become language rules and less of a cog¬ 
nitive load for developers. 

<http://www.path.berkeley.edu/> 

<http://www.path.berkeley.edu/shift> 

<http://www.path.berkeley.edu/smart-ahs> 
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Design and Semantics of Quantum: A 
Language to Control Resource 
Consumption in Distributed Computing 

Luc Moreau, University of 
Southampton, and Christian 
Queinnec, Universite de Paris 

With the advent of mobile agents comes 
increased interest in the ability to control 
the resource consumption of computa¬ 
tions either because one needs to pay for 
such consumption or because one is pro¬ 
viding the resources for others to con¬ 
sume. The DSL Quantum was developed 
for users to specify and enforce resource 
consumption limits and patterns for dis¬ 
tributed computing. Quantum is the syn¬ 
thesis of three ideas: 

■ Quotas of energy can be associated 
with computations, and energy is being 
consumed during every evaluation 
step. 

■ Asynchronous notifications inform 
[interested parties] of energy exhaus¬ 
tion or computation termination. 

■ Mechanisms exist to transfer energy to 
or from computations; supplying more 
energy to a computation gives the right 
to continue the computation, and 
removing energy from a computation 
acts as energy-based preemption. 

This paper contrasts Quantum with a 
broad variety of similar work in this field. 

<http://diana.ecs.soton.ac.uk/-lavm/> 

Domains of Concern in Software 
Architectures and Architecture 
Description Languages 

Nenad Medvidovic and David S. 
Rosenblum, University of California, 
Irvine 

Architecture Description Languages 
(ADLs) abound, but, as often happens 
when there is not yet agreement on what 
the problem is, these “solutions” differ 
widely, especially in their coverage of 
software architectural concerns. 
Medvidovic presented a comprehensive 
framework of architectural concerns and 


evaluated several major ADLs with 
respect to this framework. More under¬ 
standing of the domain(s), how they 
relate to application domains, and what 
effect they should have on ADLs are 
required, noted Medvidovic. 

Medvidovics framework showed the kind 
of analysis that one can imagine forming 
the basis for a new DSL; whether it is 
arrived at by virtue of a formal process or 
by intuition, at some point, an under¬ 
standing of the domain in this depth 
becomes necessary. Watch this space for a 
DSL. 

<http://www.ics.uci.edu/pub/arch 

/sw-and-pubs.html> 

Session: Abstract Syntax Trees 

This session concentrated on a funda¬ 
mental building block of language tools: 
the Abstract Syntax Tree. Papers were 
presented that discussed superior tools 
and techniques for representing such 
trees, searching them, and manipulating 
them. 

The Zephyr Abstract Syntax Description 
Language 

Daniel C. Wang, Andrew W. Appel, 

Jeff L. Korn, and Christopher S. 

Serra, Princeton University 

One area where DSLs shine is in the cre¬ 
ation of a glue or interchange language 
that can serve as input to various auto¬ 
mated program generators. Such meta¬ 
programming languages can aid in the 
integration of tools from diverse sources. 
The Zephyr Abstract Syntax Description 
Language (ASDL) was designed to pro¬ 
vide a concise notation for describing 
abstract syntax trees. This notation is 
processed by several companion tools 
that generate data structure definitions 


and procedures in several target lan¬ 
guages for converting ASTs to and from a 
standardized flat representation (pickles). 
Interoperation of compiler components 
is greatly facilitated by the capability to 
exchange ASTs easily. As a proof of con¬ 
cept, Wang described the use of the 
Zephyr ASDL to respecify the Stanford 
University Intermediate Format (SUIF) 
(among others), with impressive reduc¬ 
tion in “program” size. 

<http://www.cs.virginia.edu/zephyr/> 

<http://www.cs.virginia.edu/zephyr/asdl.html> 

<http://www.cs.princeton.edu/-danwang/zdoc 

/slp.html> 

<http://www.cs.princeton.edu/~danwang/zdoc 

/ztalk.pdf> 

ASTL0G: A Language for Examining 
Abstract Syntax Trees 

Roger F. Crew, Microsoft Research 

Crew described a clever and useful adap¬ 
tation of Prolog for locating and analyz¬ 
ing complex syntactic constructs in pro¬ 
gram sources (as opposed to the lexical 
searching capabilities of tools such as 
Awk and grep). ASTLOG was inspired by 
Prolog and its implicit pattern-matching 
and backtracking capabilities. Program 
source, instead of being converted to a 
Prolog fact database, can be directly 
examined by predicates present in AST¬ 
LOG. This feature is the key to making 
this approach feasible for examining large 
programs. The principal consequence of 
the inclusion of these predicates is what 
Crew termed an inside-out functional 
programming style, which turns out to be 
particularly suitable for searching and 
pattern matching on parse-trees. 
Performance of the system on substantial 
real-world examples is comparable to the 
time taken for compilation. 

<http://www.research.mlcrosoft.com/%7Erfc 

/default.htm> 


12 


Vol. 23 No. 1 ;login: 


KHEPERA: A System for Rapid 
Implementation of Domain Specific 
Languages 

Rickard E. Faith, Lars S. Nyland, and 
Jan F. Prins, University of North 
Carolina, Chapel Hill _ 

Check this out if you're looking for sup¬ 
port for DSL development: KHEPERA is 
a toolkit that creates DSL processors by 
generating source-to-source translators 
that rely on sophisticated tree-based 
analysis and manipulation to provide 
ease of implementation and superior 
debugging information. Systems built 
with KHEPERA not only provide support 
for debugging DSL translators them¬ 
selves, but also support debugging the 
end-user's DSL program. Faith started 
with a software problem in which repeti¬ 
tive work was being performed on cus¬ 
tom translators for the DSL PROTEUS, 
and he was thus motivated to find an 
automated way of generating DSL trans¬ 
lators. Such a system is advantageous 
because of the recognition that DSLs are 
likely to evolve. Such evolution implies 
frequent syntax and other translator- 
affecting changes. KHEPERA itself con¬ 
tains a DSL - the KHEPERA 
Transformation Language - that 
describes the fundamental tree matching 
and manipulation primitives required to 
specify a source-to-source translator. 

<http://www.cs.unc.edu/~faith/khepera.html> 

Session: Embedded Languages 
and Abstract Data Types 

This session was the combination of two 
topics: how fully supporting a useful 
abstract data type may require a DSL, 
and what kinds of considerations one 
faces when using the embedded approach 
to implement a DSL. The papers covering 
the former topic showed two cases where 
supporting an abstract data type required 


features that aren’t available in general- 
purpose languages, and therefore a DSL 
was the best recourse. The latter topic's 
papers, based on actual experiences, cata¬ 
loged many of the choices (and their con¬ 
sequences) that are encountered when 
implementing a DSL as an embedded 
language. 

DiSTiL: A Transformation Library for 
Data Structures 

Yannis Smaragdakis and Don Batory, 
University of Texas, Austin 

The domain for DiSTiL is that of com¬ 
plex container data structures. The 
authors argue that these data types 
should have uniform interfaces that allow 
the application and implementation to 
evolve independently. The implementa¬ 
tion of DiSTiL was described as an exten¬ 
sion of Microsoft’s Intentional Program¬ 
ming system, which is discussed in some 
detail within the paper. Furthermore, 
work described in this paper develops a 
metaprogramming framework above IP 
called “generational scoping,” which the 
paper concludes might develop into a 
general-purpose set of primitives for 
describing program generators. In addi¬ 
tion to describing the primary technical 
contribution surrounding DiSTiL, the 
paper enumerates many conclusions 
about the suitability of IP and its poten¬ 
tial influence on DSL design, implemen¬ 
tation, and use. 

<http://www.research.microsoft.com/research/ip 

/tedb/page6.html> 

Programming Language Support for 

Digitized Images or 

The Monsters in the Closet 

Daniel E. Stevenson and Margaret M. 
Fleck, University of Iowa 

In this work, Fleck argues that language 
support in the form of a new abstract 
data type, the “sheet,” and various associ¬ 
ated primitives can dramatically simplify 
the task of programmers writing in the 
field of computer vision (image under¬ 
standing) algorithms. A host of benefits 


other than direct programming relief 
accrues: easier collaboration and teaching 
and replication of research results. By 
codifying various “hard” parts of image 
processing into language primitives, Fleck 
hoped to get her colleagues to focus on 
images instead of programming. She also 
challenged DSL designers to bring the 
appropriate level of programming lan¬ 
guage abstraction (via a DSL) to this 
field, claiming that previous approaches 
are either too high or too low. The last 
half of this paper describes the particular 
aspects of computer vision that should be 
supported in a DSL and a proposed 
instance of this DSL named Envision. 

<http://www.cs.hmc.edu/~fleck/envision 

/envision.html> 


Modelling Interactive 3D and 
Multimedia Animation with an 
Embedded Language 

Conal Elliott, Microsoft Research 

Fran is a DSL for describing and compos¬ 
ing animations. A key insight behind 
Fran is that an animation can be thought 
of as a function of time. Elliott suggested 
that much animation work is frustrated 
by the level of detail required and the 
fundamental mismatch between the 
medium and the computer. For instance, 
computers operate in discrete steps, 
whereas time is continuous; or, for exam¬ 
ple, single-processing computers must be 
used to implement concurrent anima¬ 
tions. The declarative nature of Fran alle¬ 
viates these problems. Although Elliott’s 
talk centered on successively complex 
animation examples, the corresponding 
paper conveys a wealth of insight into 
design and implementation techniques 
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for domain-specific languages, particular¬ 
ly in its discussion of modelling and 
host-language embedding. 

<http://www.research.microsoft.com/~conal/fran 

/default.htm> 

Also see Landing “The Next 700 
Programming Languages, ” 
Communications of the ACM, March 
1966, pp. 157-164. 

A Special-Purpose Language for Picture 
Drawing 

Samuel Kamin and David Hyatt, 
University of Illinois, Urbana- 
Champaign 

Kamin described an experiment in 
domain-specific language design and 
implementation. Inspired by PIC, Kamin 
reproduced a set of drawing primitives 
implemented within Standard ML. 

Kamin showed the design and evolution 
of his language, FPIC, carefully illuminat¬ 
ing his design decisions at each step along 
the way. He also revealed the trade-offs 
inherent in his choice to use the embed¬ 
ded-language implementation approach. 
Kamin noted one interesting limitation of 
the embedded approach: complications 
can arise because the ordinary language 
has an environment distinct from that 
used by the embedded language’s primi¬ 
tives. Nonetheless, Kamin concluded that 
the cost-benefit ratio of the embedded 
language approach is favorable. 

<http://www-sal.cs.uiuc.edu/~kamin/fpic> 

INVITED TALKS 

Synchronous Languages - An 
Experience in Domain-Specific 
Language Design 

Gerard Berry, Ecole des Mines de 
Paris, Centre de Mathematiques 
Appliquees: INRIA, Projet Meije 

Berry presented ideas about DSLs drawn 
from his experience in designing and 
using Esterel, a language for program¬ 
ming deterministic reactive systems (sys¬ 


tems that execute indefinitely, reacting 
deterministically to asynchronous 
inputs). Berry’s inquiry was quite thor¬ 
ough in both its breadth and detail; how¬ 
ever, a few key points can be selected for 
special mention. 

When DSL designers wish to implement 
their language by the embedded 
approach, care must be taken to consider 
whether the host language is too rich or 
lacks a precise definition. This would 
complicate rigorous analysis. 

For safety-critical applications, a sound 
mathematical foundation, and therefore a 
precise semantics, is an absolute necessity 
for the language. Automated analysis 
depends upon it. 

There should be a compelling reason for 
introducing a new language. Either useful 
mathematical properties or the abstrac¬ 
tion of complex computation is a suitable 
reason. 

Sometimes the domain on which a 
designer is focused can be enlarged from 
the immediate application to a broader, 
more foundational one, in which case the 
resulting DSL can be more widely useful. 

Orthogonality of language features 
should be supported. 

It is the particular mathematical proper¬ 
ties of a formalism and its usefulness, not 
just its mere existence, that ultimately 
determines the value of any formalism. 

It is a myth that DSLs must be less effi¬ 
cient than general-purpose programming 
languages. Because DSLs tend to be small 
and may operate at quite high levels, 
sophisticated optimizations may be feasi¬ 
ble. Or DSLs may perform functions that 
are impractical for a human, thereby 
increasing the scale at which a solution 


can be obtained or yielding efficient solu¬ 
tions without the cost of hand coding. 

Berry’s conclusion: “language design 
never ends.” 

For interested readers, much more infor¬ 
mation, including the latest Esterel com¬ 
piler, can be had at 

<http://www.inria.fr/meije/esterel/esterel-eng.html> 

Intentional Programming - An Ecology 
for Abstractions 

Charles Simonyi, Chief Architect, 
Microsoft 

Charles Simonyi presented an overview 
of Intentional Programming (IP), which 
is referred to in Microsoft papers various¬ 
ly as a process, a programming environ¬ 
ment, and an ecology. From a DSL-design 
perspective, a novel aspect of IP is that it 
seeks to reduce or eliminate the rigidity 
of syntax in programming languages. 
Instead of a text-based syntax, intentional 
programs are created “preparsed” as trees 
of nodes (the intentions) aimed at cap¬ 
turing the programmer’s intent. Each 
node can be thought of as an object or 
component, possibly quite fine grained, 
that presents an appearance to the pro¬ 
grammer and is capable of behavior. 

Both the appearance and the implemen¬ 
tation of the behavior are permitted to 
change; however, the intention remains 
the same, as do its relationships with 
other intentions in the intentional pro¬ 
gram. Intentions can operate on other 
intentions to transform them to forms 
already understood by an IP system. Such 
intention-transforming intentions are 
called enzymes, in keeping with the bio¬ 
logical metaphors. 

Why program this way? The hope is that 
the adoption of IP will create an environ¬ 
ment where the biological principles of 
evolution will be brought to bear on soft¬ 
ware componentry in the hopes that the 
“fittest” will prevail. Simonyi envisions a 
vast soup of intentions, each vying for a 
place in your programs. 
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IP needs more explanation than an invit¬ 
ed talk (or its review) can provide; there¬ 
fore, I strongly encourage interested par¬ 
ties to pursue this topic by visiting 
<http://www.research.microsoft.com/> and 
searching for “intentional programming” 
or perhaps just by starting with these two 
pages: 

■ The Death of Computer Languages, the 
Birth of Intentional Programming 
<http://www.research.microsoft.com/pubs 
/tr-95-52a.html> 

■ Microsoft Research Intentional 
Programming 

<http://www.research.microsoft.com/ip 

/default.htm> 

Aspect-Oriented Programming - 
Improved Support for Separation of 
Concerns in Design and Implementation 

Gregor Kiczales, Xerox Palo Alto 
Research Center 

Concluding the conference was the privi¬ 
lege of hearing Gregor Kiczales, co¬ 
author of “The Art of the Metaobject 
Protocol.” He chose to talk about his 
most recent work, which he calls Aspect- 
Oriented Programming (AOP), in which 
another “domain” (really a view or slice) 
for programs is introduced. It leads to 
programs that are much more tolerant of 
changes in the requirements of runtime 
behavior and other systemic properties. 

Starting from first principles, Kiczales 
reminded us how (in general) we build 
complex systems by first partitioning the 
system into cognitively manageable parts 
- the separation of concerns, or decom¬ 
position - and then by constructing 
and/or composing implementation ele¬ 
ments in a way that is “suggested” by the 
decomposition. In this way, concerns that 
are known from the outset tend to appear 
localized in the implementation and per¬ 
mit relatively easy modification in the 
face of changing requirements. There is, 
however, a class of concerns for which 
this fails dramatically - systemic proper¬ 
ties (e.g., runtime behavior). The interac¬ 


tion of software components whose 
structure was determined largely by static 
considerations gives rise to what Kiczales 
terms “emergent entities.” The recogni¬ 
tion of these entities provides the key 
insight that motivates AOP: emergent 
entities are important, are difficult to 
manage classically, and require languages 
and tools for their explicit description 
and use. 

Emergent entities are important because 
they can represent things like perfor¬ 
mance concerns, synchronization behav¬ 
iors, memory usage, and replication 
properties. They are difficult to manage 
classically because accommodating any 
single one could involve changes to many 
components in a system. This arises 
because emergent entities involve the 
interaction of components and therefore 
cut across component boundaries. 
Kiczales allows that there is frequently a 
way to refactor a design post hoc to 
accommodate changes in the runtime 
behavior requirements; however, what is 
needed is something more accommodat¬ 
ing of such changes. Finally, emergent 
entities need language and tool support 
precisely because they do not (yet) 
appear explicitly in the implementation 
of a system. 

The mechanism Kiczales proposes to 
manage emergent entities is the “aspect,” 
which he defines as a “modular unit of 
control over emergent entities.” He fur¬ 
ther proposes (and has implemented) 
“aspect languages” and their translators, 
“aspect weavers.” The translators work by 
taking a modular program and the 
expression of one or more aspects and 
weaving the codes together, yielding a 
program that reflects the original modu¬ 
lar system, modified to account for the 


aspect. Through this technique, the 
aspect can be coded in a compact, local 
form and yet, through the actions of the 
aspect weaver, have a widely distributed 
effect on the implementation. Thus, AOP 
is a “modularity for that which was previ¬ 
ously amodular” and is robust in the face 
of changes in the requirements for run¬ 
time behaviors and other systemic prop¬ 
erties. 

Slides from a similar talk are available at: 
<http://www.parc.xerox.com/spl/projects/aop/forum 
/index.htm> 

BOFS 

There were three Birds-of-a-Feather 
(BOF) sessions at DSL ’97, all of which 
were arranged by interested parties before 
the conference began. In part, the BOFs 
were a great success because of this 
preparation, and this points the way to a 
potential approach for increasing the 
likelihood of having interesting and well- 
attended BOFs. 

Musical Languages 

Attendees of the Musical Languages BOF 
session were treated to a number of 
speakers, some human, some electro¬ 
mechanical. The organizer, Tim 
Thompson, brought musical equipment 
and recordings with him, as did some of 
the other presenters, including Paul 
Hudak, the conference’s keynote speaker. 
Several music and sound composition 
systems were demonstrated and contrast¬ 
ed. These exposed themes such as the use 
of interactive or visual DSLs and their 
relationship(s) to text-based languages 
and the nature of the interaction between 
domain experts and the language devel¬ 
opers. 

Patenting Domain-Specific Languages 

At first glance, having a BOF concerned 
with intellectual property at a Domain- 
Specific Language conference might 
strike one as unusual, and it is. But it was 
certainly useful and intriguing. Christa 
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Schwartz, a onetime software designer at 
Bell Labs and now a patent attorney, 
acquitted herself very well in delivering 
an interesting, realistic, and thought- 
provoking presentation about DSLs from 
the intellectual property perspective. 
Covering the background of patent law 
briefly, she went on to describe what ele¬ 
ments are involved in both the decision 
to patent and also the process of patent¬ 
ing a Domain-Specific Language, its 
concepts and/or its implementation. 
Drawing on her interdisciplinary knowl¬ 
edge, Schwartz finished with an example 
in which she patented a language all 
DSLers should know: YACC. 

Program Generators 

This discussion began with Samuel 
Kamin’s proposal that program genera¬ 
tors should be considered programming 
languages that have programs and pro¬ 
gram fragments as their intrinsic data 
types instead of the more usual charac¬ 
ters, integers, and floating point num¬ 
bers. These program fragments parame¬ 
terize a generator and determine the 
range of possible output programs, effec¬ 
tively defining an application domain. 
Kamin further framed the discussion by 
suggesting some points to ponder when 
considering program generators: 

■ How can (or even should) the logic 
that generates the code and the “tem¬ 
plate” of the code be separated? 

■ To what extent can ideas and features 
from other languages and implementa¬ 
tions (such as static type checking, 
recursion, and optimization) be 
applied to program generators? 

■ What kinds of languages work well as 
the target language of a program gen¬ 
erator? 

■ What is a good way to organize, struc¬ 
ture, or maintain a program generator? 

■ When should a program generator, 


Quotable Quotes from 
the DSL Conference 

Satish Chandra: “Avoid frustrating 
potential users. Avoid potential frustrat¬ 
ing users.” 

Gerard Berry: “Language Design Never 
Ends” (just ask B.S.). 

“0 is a beautiful number.” 

Charles Simonyi: “It’s better to have DS 
Bugs than bugs bugs.” 

“I don’t believe in simplicity. Simplicity 
is a trap.” 

“Haskel - you will really have to commit 
to it before you don’t like it.” 

“I always feel funny when I hear the 
word ‘simplicity.’ ” 

Samuel Kamin: “Fn Langs: you either 
love ’em or you don’t know what you’re 
doing.” 

Gregor Kiczales: “You sound just like 
someone from PARC: you talk a long 
time about a simple problem.” 

“Exception handling: many many power¬ 
ful minds have gone there ... and come 
back.” 

Unknown limo driver: “What’s this 
Unisex LSD Conference?” 


rather than a full-fledged language or 
an embedded approach, be used to 
solve a problem? 

The popularity of this BOF and the con¬ 
tent of the discussion revealed substantial 
interest in program generators as a tech¬ 
nique for creating parameterized solu¬ 
tions in certain problem domains. 
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KEYNOTE ADDRESS 
Generation X in IT 

Randy Johnson and Harris Kern, R&H 
Associates Inc. 

Summary by Carolyn M. Hennings 

Randy Johnson and Harris Kern spoke 
about the characteristics of a portion of 
today’s workforce referred to as 
Generation X and the impact it has on 
traditional IT departments. The challenge 
to existing IT departments is identifying 
the nature of the Generation X work¬ 
force, clarifying why these characteristics 
are potentially an issue, and determining 
how to manage the situation in the 
future. 

In the early 1990s, industry labelled 
Generation X - persons born between 
1964 and 1978 - as “slackers”; however, 
most are entrepreneurial, like change and 
diversity, and are technically literate. In 
contrast, the traditional IT organization 
was built on control and discipline. 

As technology has moved away from a 
single machine to a networked comput¬ 
ing model, the nature of the IT business 
has changed. The speakers noted that IT 
departments had historically relinquished 
control of personal computers and local 
area networks. IT management has come 
to the realization that these are essential 
elements of the success of mission-criti¬ 
cal applications. As a result, there must be 
some control. 

Johnson and Kern suggested IT manage¬ 
ment focus on the following areas: 
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■ Teamwork. Encourage people to work 
together and rely on individuals to do 
their jobs. 

■ Communication. Improve communica¬ 
tion within the organization and with 
the customer. 

■ Involvement. Rather than direction 
from above, involve the team in deci¬ 
sions and planning. 

■ People. Encourage a “can do, be smart” 
attitude with some discipline. 

■ Process. Institute the minimum and 
sufficient processes to support the 
organization. 

They suggested that this could be consid¬ 
ered “creating Generation Y.” These peo¬ 
ple and relationships will be needed to 
build successful IT organizations. The IT 
department must become a true services 
organization. To accomplish this, the 
department must win back the responsi¬ 
bility for technology decisions, reculture 
the staff to support diversity and change, 
market and sell the services, train staff 
members, and focus on customer satis¬ 
faction. 

The department must communicate 
within the IT organization and with cus¬ 
tomers. Defining architectures, standards, 
support agreements, and objectives will 
make great strides in this area. The defin¬ 
ition and support of the infrastructure 
from the desktop to the network, data 
center, and operations is an essential step. 
Defining “production” and what it means 
to the customer in terms of reliability, 
availability, and serviceability goes a long 
way in opening communication and 
expectations. 

System management processes with stan¬ 
dards and procedures modified from the 
mainframe discipline are necessary steps. 
The speakers cautioned organizations 
against bureaucracy and suggested focus¬ 
ing on producing only “minimum and 
sufficient documentation.” Implemen¬ 
ting deployment methodologies and 


processes was strongly encouraged, as 
well as developing tools for automating 
these processes. 

REFEREED PAPERS TRACK 

Session: Monitoring 

Summaries by Bruce Alan Wynn 

Implementing a Generalized Tool for 
Network Monitoring 

Marcus J. Ranum, Kent Landfield, 
Mike Stolarchuk, Mark Sienkiewicz, 
Andrew Lambeth, and Eric Wall, 
Network Flight Recorder Inc. 

Most network administrators realize that 
it is impossible to make a network 
unbreachable; the key to network security 
is to make your site more difficult than 
another so would-be intruders find easier 
pickings elsewhere. 

In this presentation, Ranum further pos¬ 
tulated that when a network break-in 
does occur, the best 
reaction (after repelling 
the invader) is to deter¬ 
mine how access was 
gained so you can block 
that hole in your securi¬ 
ty. To do this, the author 
presents us with an 
architecture and toolkit 
for building network 
traffic analysis and event 
records: the Network 
Flight Recorder (NFR). 

The name reflects the 
similarity of purpose to 
that of an aircraft s flight 
recorder, or “black box,” which can be 
analyzed after an event to determine the 
root cause. 

Further, he postulated that information 
about network traffic over time may be 
used for trend analysis: identifying 
approaching bottlenecks as traffic 
increases, monitoring the use of key 
applications, and even monitoring the 
network traffic at peak usage periods in 


order to plan the best time for network 
maintenance. Thus, this information 
would be useful for network managers in 
planning their future growth. 

The NFR monitors a promiscuous packet 
interface in order to pass visible traffic to 
an internally programmed decision 
engine. This engine uses filters, which are 
written in a high-level filter description 
language, read into the engine, compiled, 
and preserved as byte-code instructions 
for fast execution. Events that pass 
through the filters are passed to a combi¬ 
nation of statistical and logging back-end 
programs. The output of these back-ends 
can be represented graphically as his¬ 
tograms or as raw data. 

Ranum can be reached at <mjr@clark.com>; 
the complete NFR source code, including 
documentation, Java class source, deci¬ 
sion engine, and space manager, is cur¬ 
rently available from <http://www.nfr.net> for 
noncommercial research use. 


Extensible, Scalable Monitoring for 
Clusters of Computers 

Eric Anderson, University of 
California, Berkeley 

The Cluster Administration using 
Relational Databases (CARD) system is 
capable of monitoring large clusters of 
cooperating computers. Using a Java 
applet as its primary interface, CARD 



Marcus J. Ranum, presenter of the Best Paper Award winner at LISA 
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allows users to monitor the cluster 
through their browser. 

CARD monitors system statistics such as 
CPU utilization, disk usage, and execut¬ 
ing processes. These data are stored in a 
relational database for ease and flexibility 
of retrieval. This allows new CARD sub¬ 
systems to access the data without modi¬ 
fying the old subsystems. CARD also 
includes a Java applet that graphically 
displays information about the data. This 
visualization tool utilizes statistical aggre¬ 
gation to display increasing amounts of 
data without increasing the amount of 
screen space used. The resulting informa¬ 
tion loss is reduced by varying shades of 
the same color to display dispersion. 

Anderson can be reached at 
<eanders@u98.c$.berkeley.edu>. CARD is 
available from <http://now.cs.berkeley.edu 
/Sysadmin/esm/intro.html>. 

Monitoring Application Use 
with License Server Logs 

Jon Finke, Polytechnic Institute 

Many companies purchase software 
licenses using their best estimate of the 
number required. Often, the only time 
this number changes is when users need 
additional licenses. A side effect of this is 
that many companies pay for unused 
software licenses. In this presentation, Jon 
Finke described a tool for monitoring the 
use of licensed software applications by 
examining license server logs. 

This tool evolved from one designed to 
track workstation usage by monitoring 
entries in the wtnp files. Because most 
license servers record similar information 
(albeit in often radically different for¬ 
mats), the tool was modified to monitor 
license use. 

Information can be displayed in a spread¬ 
sheet or as a series of linear graphs. The 
graphs provide an easy visual estimate of 
the number of software licenses actually 
in use at a given point in time, or over a 
period of time. Analysis of this informa¬ 


tion can quickly uncover unneeded 
licenses at your site. 

Currently, the tool interfaces with Xess (a 
commercial spreadsheet available from 
Applied Information Services), Oracle, 
and Simon (available from <ftp://ftp.rpi.edu/ 
pub/its-release/simon/README.simon>). 

Finke can be contacted at <finkej@rpi.edu>. 

Session: The Business of 
System Administration 

Summaries by Brad C. Johnson 

Automating 24x7 Support Response 
to Telephone Requests 

Peter Scott, California Institute of 
Technology 

Scott has designed a system, called 
helpline, that provides automated 
answering of a help desk telephone dur¬ 
ing nonpeak hours and is used for notify¬ 
ing on-call staff of emergencies within a 
short amount of time (minutes or sec¬ 
onds) once a situation is logged in the 
system (scheduler) database. This system 
was designed mainly to be cheap and 
therefore mostly applicable to sites with 
low support budgets. The system is com¬ 
prised of source code written in Perl, the 
main scheduler information base written 
in SGML, and two dedicated modems - 
one for incoming calls (for problem 
reporting) and one for outgoing calls (for 
notification). 

The rationale for creating helpline is that 
most other available software that was 
sufficient to provide automated support 
cost more than $100,000. Several tools 
that cost less were discovered, but they 
did not provide sufficient notification 
methods (such as voice, pager, and email 
according to a schedule). Recent entries 
into this market include a Telamon prod¬ 
uct called Tel Alert, which requires pro¬ 
prietary hardware, and VoiceGuide from 
Katalina Technologies, which runs only 
on Windows. There is also available some 
freeware software called tpage, but it con¬ 
centrates on pagers, not on voice phones. 


The key to the system is a voice-capable 
modem. When an incoming call is 
answered by the modem daemon, it pre¬ 
sents a standard hierarchical phone menu 
- a series of prerecorded sound files that 
are linked to the appropriate menu 
choice. Independent of the phone menu 
system is the notifier and scheduler com¬ 
ponent. When an emergency notification 
occurs, the scheduler parses a schedule 
file (written in SGML) to determine who 
is on call at the time, determines what 
profile (i.e., action) is appropriate based 
on the time and situation, and takes the 
action to contact the designated on-call 
person. Multiple actions can be associat¬ 
ed with an event, and if the primary noti¬ 
fication method fails, alternate methods 
can be invoked. 

Unfortunately, this software may not be 
completed for a long time (if ever) 
because funding and staff have been 
assigned to other projects, although the 
current state of the source code is avail¬ 
able for review. Send email with contact 
information and the reason for your 
request to <jks@jpl.nasa.gov>. Additionally, 
in its current state, there are some signifi¬ 
cant well-known deficiencies such as data 
synchronization problems (which require 
specialized modem software), (over)sen- 
sitivity to the load of the local host (a 
host that is assumed to be reliably avail¬ 
able), and virtually no available hard 
copy documentation. 

Turning the Corner: Upgrading Yourself 
from “System Clerk” 
to “System Advocate” 

Tom Limoncelli, Bell Labs, Lucent 
Technologies 

Limoncelli believes that many adminis¬ 
trators can be classified in one of two 
ways: as a system clerk or as a system 
advocate. A system clerk takes orders, 
focuses mainly on clerical tasks, and per¬ 
forms many duties manually. A system 
advocate is focused on making things 
better, automates redundant tasks, works 
issues and plans from soup to nuts, and 
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treats users as customers to create 
respectful, understanding partnerships 
for resolving problems. The key to job 
satisfaction, feeling better, and getting 
better raises is to make the transition 
from clerk to advocate. 

Making a successful transition to system 
advocate requires converting bad (sub¬ 
servient) habits into good (cooperative) 
ones, creating spare time for better com¬ 
munication and quality time for planning 
and research, and automating mundane 
and repetitive tasks. 

Although changing habits is always hard, 
it’s important to concentrate on getting a 
single success. Follow that with another 
and another, and over time these experi¬ 
ences will accumulate and become the 
foundation for good habits. 


To find spare time, people need to think 
outside of the box and be more critical 
and selective about where their time is 
spent. Suggestions for regaining time 
include stop reading USENET, get off 
mailing lists, take a time management 
course, filter mail (and just delete the 
ones that you can’t get to in a reasonable 
time - e.g., at the end of the week), and 
meet with your boss (or key customer) to 


prioritize your tasks and remove extrane¬ 
ous activities from your workload. 

Automating tasks, within the realm of a 
system administrator, requires competen¬ 
cy in programming languages such as 
Perl, Awk, and MAKE. These are lan¬ 
guages that have proven to be robust and 
provide the functionality that is necessary 
to automate complex tasks. 

Transforming the role of clerk to advo¬ 
cate is hard and requires a change in atti¬ 
tude and working style to improve the 
quality of work life, provide more value 
to customers, and create a more profes¬ 
sional and rewarding environment. 
However, the effort required to make this 
transition is worth it. Simply put, vendors 
can automate the clerical side of system 
administration, but no vendor can auto¬ 
mate the value of a system advocate. 


How to Control and Manage Change in a 
Commercial Data Center Without Losing 
Your Mind 

Sally J. Howden and Frank B. 
Northrup, Distributed Computing 
Consultants Inc. 

Howden and Northrup presented a 
methodology to ensure rigor and control 
over changes to a customers computing 


environment. They (strongly) believe that 
the vast majority of problems created 
today are caused by change. When change 
occurs unsuccessfully, the result can 
range from lost productivity to financial 
loss. Change is defined as any action that 
has the potential to change the environ¬ 
ment and must consider the impact from 
software, hardware, and people. Using the 
rigorous method that was outlined will 
lower the overall risk and time spent on 
problems. They believe that this rigor is 
required for all changes, not just for sig¬ 
nificant or complex ones. 

There are eight main steps outlined in 
this methodology: (1) Establish and doc¬ 
ument a base line for the entire environ¬ 
ment. (2) Understand the characteristics 
of the change. (3) Test the changes in 
both an informal test and formal prepro¬ 
duction environment. (4) Fully docu¬ 
ment the change before, during, and after 
implementation. (5) Review the change 
with all involved parties before placing it 
into the production environment. 

(6) Define a detailed back-out strategy if 
the change fails in the production envi¬ 
ronment. (7) Provide training and educa¬ 
tion for all parties involved in the change. 
(8) Periodically revisit the roles and 
responsibilities associated with the 
change. 

The authors were quite firm about testing 
a change in three physically distinct and 
separate environments. The first phase 
includes (unit) testing of the change on 
the host(s) involved in development. The 
second phase requires testing in a prepro¬ 
duction environment that, in the best 
case, is an exact duplicate of the produc¬ 
tion environment. The third phase is 
placing the change in the actual produc¬ 
tion environment. 

When pressed on the suitability of using 
this (heavyweight) process on all changes, 
the authors stated that the highest priori¬ 
ty activities are to fully document change 
logs and to create thorough work plans. 
The paper notes, however, that although 
this process does generate a significant 
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amount of work by the administrators 
before a given change, it has (over time) 
shown to reduce the overall time spent - 
especially for repeated tasks, when trans¬ 
ferring information to other staff, when 
secondary staff are on duty, and when 
diagnosing problems. 

Session: System Design 
Perspectives 

Summaries by Mark K. Mellis 

Developing Interim Systems 

Jennifer Caetta, NASA Jet Propulsion 
Laboratory 

Caetta addressed the opportunities pre¬ 
sented by building systems in the real 
world and keeping them running in the 
face of budgetary challenges. 

She discussed the role of interim systems 
in a computing environment - systems 
that bridge the gap between today’s oper¬ 
ational necessities and the upgrades that 
are due three years from now. She pre¬ 
sented the principles behind her system 
design philosophy, including her exten¬ 
sions to the existing body of work in the 
area. Supporting the more academic dis¬ 
course are a number of cogent examples 
from her work supporting the Radio 
Science Systems Group at JPL. I especially 
enjoyed her description of interfacing a 
legacy stand-alone DSP to a SparcStation 
5 via the DSP’s console serial port that 
exposed the original programmer’s 
assumption that no one would type more 
than 1,024 commands at the console 
without rebooting. 

Caetta described points to consider when 
evaluating potential interim systems pro¬ 
jects, leveraging projects to provide 
options when the promised replacement 
system is delayed or canceled, and truly 
creative strategies for financing system 
development. 


A Large Scale Data Warehouse 
Application Case Study 

Dan Pollack, America Online 

Pollack described the design and imple¬ 
mentation of a greater-than-one-terabyte 
data warehouse used by his organization 
for decision support. He addressed such 
issues as sizing, tuning, backups, perfor¬ 
mance tradeoffs and day-to-day opera¬ 
tions. 

He presented in a straightforward man¬ 
ner the problems faced by truly large 
computing systems: terabytes of disk, 
gigabytes of RAM, double-digit numbers 
of CPUs, 50 Mbyte/sec backup rates - all 
in a single system. America Online has 
more than nine million customers, and 
when you keep even a little bit of data on 
each of them, it adds up fast. When you 
manipulate that data, it is always compu¬ 
tationally expensive. 


The bulk of the presentation discussed 
the design of the mass storage IO subsys¬ 
tem, detailing various RAID configura¬ 
tions, controller contention factors, back¬ 
up issues, and nearline storage of “dor¬ 
mant” data sets. It was a fascinating 
examination of how to balance the 
requirements of data availability, raw 
throughput, and the state of the art in 
UNIX computation systems. He also 
described the compromises made in the 
system design to allow for manageable 
system administration. For instance, if 
AOL strictly followed the database ven¬ 
dor’s recommendations, they would have 
needed to use several hundred file sys¬ 
tems to house their data set. By judicious 
use of very large file systems so as to 
avoid disk and controller contention, 
they were able to use a few large (!) file 
systems and stripe the two gigabyte data 
files across multiple spindles, thereby pre¬ 
serving both system performance and 
their own sanity. 
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Shuse At Two: Multi-Host Account 
Administration 

Henry Spencer, SP Systems 

Spencer’s presentation described his 
experiences in implementing and main¬ 
taining the Shuse system he first 
described at LISA ’96. He details the 
adaptation of Shuse to support a whole¬ 
sale ISP business and its further evolution 
at its original home, Sheridan College, 
and imparted further software engineer¬ 
ing and system design wisdom. 

Shuse is a multi-host administration sys¬ 
tem for managing user accounts in large 
user communities, into the tens of thou¬ 
sands of users. It uses a centralized archi¬ 
tecture. It is written almost entirely in the 
expect language. (There are only about 
one hundred lines of C in the system.) 
Shuse was initially deployed at Sheridan 
College in 1995. 

Perhaps the most significant force acting 
on Shuse was its adaptation for ISP use. 
Spencer described the changes needed, 
such as a distributed account mainte¬ 
nance UI, and reflected that along with 
exposing Sheridan-specific assumptions, 
the exercise also revealed unanticipated 
synergy, with features requested by the 
ISP being adopted by Sheridan. 

A principal area of improvement has 
been in generalizing useful facilities. 
Spencer observed in his paper, “Every 
time we’ve put effort into cleaning up 
and generalizing Shuse’s innards, we’ve 
regretted not doing it sooner. Many 
things have become easier this way; many 
of the remaining internal nuisances are 
concentrated in areas which haven’t had 
such an overhaul lately.” 

Other improvements have been in elimi¬ 
nating shared knowledge by making data- 
transmission formats self-describing, and 
in the ripping out of “bright ideas” that 
turned out to be dim and replacing them 
with simpler approaches. These efforts 
have payed off handsomely by making 
later changes easier. 


Spencer went on to describe changes in 
the administrative interfaces of Shuse, 
and in its error recovery and reporting. 

Shuse is still not available to the general 
public, but Spencer encourages those 
who might be interested in using Shuse 
to contact him at <henry@zoo.toronto.edu> 

Spencer’s paper is the second in what I 
hope will become a series on Shuse. As a 
system designer and implementor myself, 
I look forward to objective presentations 
of experiences with computing systems. 
It’s a real treat when I can follow the 
growth of a system and learn how it has 
changed in response to real-world pres¬ 
sures and constraints. Often papers 
describe a system that has just been 
deployed or is in the process of being 
deployed; it is rare to see how that system 
has grown and what the development 
team has learned from it. 

Session: Works in Progress 

Summaries by Bruce Alan Wynn 

Service Level Monitoring 

Jim Trocki, Transmeta Corp. 

Many system and network administrators 
have developed their own simple tools for 
automating system monitoring. The 
problem, proposes Jim Trocki, is that 
these tools often evolve into something 
unlike the original and in fact are not 
“designed” at all. 

Instead, Jim presents us with mon: a Perl 5 
utility, developed on Linux and tested on 
Solaris, mon attempts to solve 85% of the 
typical monitoring problems. The 
authors developed mon based upon these 
guidelines: 

■ Simple works best. 

■ Separate testing code from alert gener¬ 
ation code. 

■ Status must be tracked over time. 


The mon tool accepts input from external 
events and “monitors” (programs that 
test conditions and return a true/false 
value). The mon processes then examine 
these data and decide which should be 
presented directly to clients and which 
should trigger an alarm. 

The authors are currently expanding the 
functionality of mon to include depen¬ 
dency checking of events, severity escala¬ 
tion, alert acknowledgments via the 
client, “I’m okay now” events, asynchro¬ 
nous events, a Web interface, and a better 
name. 

The current version of mon is available at 
<http://consult.ml.org/-trockij/mon>. 

Jim Trocki can be reached at 
<trcckij@transmeta.com>. 

License Management: LICCNTL - Control 
License Protected Software Tools 
Conveniently 

Wilfried Gaensheimer, Siemens AG 

Gaensheimer presented an overview of a 
number of tools that can help control 
and monitor the use of software licenses. 
The tools can also generate reports of 
license use over time. 

For additional information on these 
tools, contact Gaensheimer at 
<wig@HL.Siemens.DE>. 

Inventory Control 

Todd Williams, MacNeal-Schwendler 
Corp. 

One of the less exciting tasks that system 
and network administrators are often 
faced with is that of taking a physical 
inventory. Typical reasons for this 
requirement include: 

■ Maintenance contract renewal 

■ Charge backs for resource use 

■ Identifying the type of machinery 

Williams began tracking his inventory by 
including comments in the system’s 
“hosts” files, but quickly outgrew this 
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mechanism when devices appeared that 
did not have an IP address, and when the 
amount of information desired made the 
“hosts” table unwieldy. 

Instead, Williams developed a database to 
track this information. He developed 
procedures to keep this information up 
to date as machinery moves in and out of 
the work site. 

For additional information on these soft¬ 
ware tools for tracking inventory, contact 
Todd Williams at 
<todd.wil!iams@macsch.com>. 

Values Count 

Steve Tylock, Kodak 

Although it may initially seem a surpris¬ 
ing topic for a technical conference, 
Tylock reintroduced the basic values of a 
Fortune 500 company: 

■ respect for the dignity of the individual 

■ uncompromising integrity 

■ trust 

■ credibility 

■ continuous improvement and personal 
renewal 

Instead of applying these to the company 
itself, Tylock suggested that system and 
network administrators could increase 
their professionalism and efficiency by 
applying these basic values to their daily 
work. 

For more information on this topic, con¬ 
tact Steve Tylock at <tylock@kodak.com>. 

Extending a Problem-Tracking System 
with PDAs 

Dave Barren, Convergent Group 

Many system and network administrators 
use one type of problem-tracking system 
or another. But because working on the 
typical system or network problem often 
means working away from one's desk, 
administrators must keep track of ticket 
status independently of the tracking sys¬ 
tem. When administrators return to their 


desk, they must “dump” the information 
into the tracking system, hoping that they 
don’t mis-key data or get interrupted by 
another crisis. 

To help alleviate this problem, Barren 
suggests using a PDA to track ticket sta¬ 
tus. Barren has developed a relatively 
simple program for his Pilot that allows 
him to download the tickets, work the 
problems, track ticket status on the Pilot, 
then return to his desk and upload the 
changes in ticket status in one easy step. 

This allows Barren to work on more tick¬ 
ets before returning to his desk and 
increases the validity of the tracking sys¬ 
tem. Barren hopes to encourage more 
users to implement this plan so that the 
increased number of Pilots will allow him 
to upload ticket status information at vir¬ 
tually any desk instead of returning to his 
own. 

For additional information on this con¬ 
cept and the software tools Barren has 
developed, contact him at 
<dcbarro@nppd.com>. 

Survey of SMTP 

Dave Parter, University of Wisconsin 

One of the beautiful things about the 
Simple Mail Transfer Protocol is that it 
allows people to use any number of 
transfer agents to deliver electronic mail 
across the world. The down side is that 
there is a hodgepodge of versions and 
“brands” of transfer agents in use, and 
nobody really knows what is in use these 
days. Except, perhaps, Dave Parter. 

To examine this issue, Parter monitored 
the incoming mail at his site for a short 
period of time. For each site that sent 
mail to his, he tested the SMTP greeting 
and tried to identify the type and version 
of the agent. His results: 

sendmail: 60% 

other/unknown: 17% 

SMAP: 3% 

PMDF: 2% 


Parter was able to identify 140 distinct 
versions of sendmail in use in this small 
sampling. ! 

Where, Parter asks, do we go from here 
with these data? He isn’t sure. If you 
would like to discuss these findings, or 
conduct your own survey, contact Parter 
at <dparter@cs.wisc.edu>. 

Session: Net Gains 

Summaries by Mark K. Mellis 

Creating a Network for Lucent Bell Labs 
Research South 

i 

Tom Limoncelli, Tom Reingold, Ravi j 
Narayan, and Ralph Loura, Bell Labs, | 
Lucent Technologies j 

This presentation described how, as a 
result of the split of AT&T Bell Labs j 
Research into AT&T Labs and Lucent Bell j| 
Labs, they transitioned from an “organi- ; 
cally grown” network consisting of four jj 
main user communities and ten main IP j 
nets (out of a total of 40 class C IP nets) 
to a systematically designed network with 
two main user communities on four 
main IP nets, renumbering, rewiring, 
cleaning up, and “storming the hallways” 
as they went. 

Unlike many projects of this scope, the 
authors planned the work as a phased 
transition, using techniques such as run¬ 
ning multiple IP networks on the same 
media and operating the legacy NIS con- f 
figuration in parallel with the new config 
to transition slowly to the new configura- J 
tion, rather than make all the changes 
during an extended down time and dis¬ 
cover a critical error at the end. They 
relate their experiences in detail, includ¬ 
ing a comprehensive set of lessons 
learned about strategy, end-user commu- 1 
nications, and morale maintenance. (“Yell j 
a loud chant before you storm the hall¬ 
ways. It psyches you up and makes your ! 
users more willing to get out of the way.”) j 

Having been faced with a network unfor¬ 
tunately typical in its complexity, and \ 
real-world constraints on system down- j 
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time, this group described their thought 
processes and methodologies for solving 
one of the problems of our time, corpo¬ 
rate reorganization. In the face of obsta¬ 
cles such as not having access to the 
union-run wiring closets and “The 
Broken Network Conundrum,” where 
one must decide between fixing things 
and explaining to the users why they 
don’t work, they divided their networks, 
fixed the problems, and got a cool T-shirt 
with a picture of a chainsaw on it, to 
boot. 

Some the tools constructed for this pro¬ 
ject are available at 
<http://www.bell-labs.com/user/tal>. 

Pinpointing System Performance Issues 

Douglas L. Urner, BSDI 

Urner gave us a well-structured presenta¬ 
tion that within the context of a case 
study on Web server performance opti¬ 
mization presents a systematic model for 
tuning services from the network connec¬ 
tion, through the application and operat¬ 
ing system, all the way to the hardware. 
His paper is a vest-pocket text on how to 
make it go faster, regardless of what “it” 
might be. 

Urner began the paper by describing an 
overview of system tuning: methodology, 
architecture, configuration, application 
tuning, and kernel tuning. He discussed 
the need to understand the specifics of 
the problem at hand - protocol perfor¬ 
mance, application knowledge, data col¬ 
lection and reduction. He then described 
tuning at the subsystem level, including 
file system, network, kernel, and memory. 
He presented a detailed explanation of 
disk subsystem performance, then went 
on to examine CPU performance, kernel 
tuning, and profiling both application 
and kernel code. 


Urners paper is about optimizing Web 
server performance, but it is really about 
much more. He describes, in detail, how 
to look at performance optimization in 
general. He encourages readers to develop 
their intuition and to establish reasonable 
bounds on performance. By estimating 
optimal performance, the system design¬ 
er can determine which of the many 
“knobs” in an application environment 
are worth “turning”, and help set reason¬ 
able expectations on what can be accom¬ 
plished through system tuning. 

Session: Configuration 
Management 

Summaries by Karl Buck 

The first two papers deal with the actual 
implementations of tools written to han¬ 
dle the specific problems. The third paper 
is an attempt to get a higher level view of 
where configuration management is 
today and make suggestions for improv¬ 
ing existing CM models. 


Automation of Site Configuration 
Management 

Jon Finke, Rensselaer Polytechnic 
Institute 

Finke presented his implementation of a 
system that not only tracks interesting 
physical configuration aspects of UNIX 
servers, but also stores and displays 
dependencies between the servers and the 
services that they provide. The configura¬ 
tion management system has an Oracle 
engine and outputs data to a Web tree, 
making for a very extensible, useful tool. 
For instance, if a license server is to be 
updated, one can find out not only all the 
other services that will be affected, but 
also the severity of those outages and 
who to contact for those services. Source 
code is available; see 

<ftpy/ftp.rpi.edu/pub/its-release/simon/README.simon> 
for details. 
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Chaos Out of Order: A Simple, Scalable 
File Distribution Facility for 
“Intentionally Heterogeneous” Networks 

Alva L. Couch, Tufts University 

The core of this paper is a file distribu¬ 
tion tool written by Couch called DISTR. 
Using DISTR, administrators of unrelat¬ 
ed networks can use the same file distrib¬ 
ution system, yet retain control of their 
own systems. DISTR can “export” and 
“import” files to and from systems man¬ 
aged by other people. Frank discussion is 
given to the existing limitations and 
potential. DISTR is available at 
<ftp://ftp.eecs.tufts.edu/pub/distr>. 

An Analysis of UNIX System 
Configuration 

Remy Evard, Argonne National 
Laboratory 

This paper is an attempt to step back and 
take a look at what is available for use in 
UNIX configuration and file manage¬ 
ment, examine a few case studies, and 
make some observations concerning the 
current configuration process. Finally, 
Evard argues for a “stronger abstraction” 
model in systems management, and 
makes some suggestions on how this can 
be accomplished. 


Session: Mail 

Summaries by Mark K. Mellis 

Tuning Sendmail for Large Mailing Lists 

Rob Kolstad, BSDI 

Kolstad delivered a paper that described 
the efforts to reduce delivery latency in 
the <inet-access@earth.com> mailing list. 

This mailing list bursts to up to 400,000 
message deliveries per day. As a result of 
the tuning process, latency was reduced 
to less than five minutes from previous 
levels that reached five days. 

Kolstad described himself as a member of 
Optimizers Anonymous, and he shared 
his obsession with us. He described the 
process by which he and his team ana¬ 
lyzed the problem, gathered data on the 
specifics, and iterated on solutions. He 
took us through several rounds of data 
analysis and experimentation, and illus¬ 
trated how establishing realistic bounds 
on performance and pursuing those 
bounds can lead to insights on the prob¬ 
lem at hand. 

Kolstad and his team eventually homed 
in on the approach of increasing the par¬ 
allelism to the extreme of using hundreds 
of concurrent sendmail processes to 
deliver the list. They also reduced time¬ 


outs for nonresponsive hosts. This, of 
course, required the creation of a number 
of scripts to automate the parallel queue 
creation. These scripts are available upon 
request from Kolstad, <kolstad@bsdi.com>. 

Kolstad closed by noting that after the 
optimizations were made, the biggest 
remaining problem was unavailability of 
recipients. He expressed his amazement 
that in a mailing list dedicated to Internet 
service providers, some one to three per 
cent of recipients were unreachable at any 
point in time. Also, even with these 
improvements, the mailing list traffic of 
mostly small messages doesn't tax even a 
single T-l to its limits. 

Selectively Rejecting SPAM Using 
Sendmail 

Robert Harker, Harker Systems 

Harker offered a presentation that 
addressed one of the hottest topics on the 
Internet today - unsolicited commercial 
email, otherwise known as spam. He 
characterizes spam, examines the differ¬ 
ent requirements for antispam processing 
at different classes of sites, and offers 
concrete examples of sendmail configura¬ 
tions that address these diverse needs. 

After his initial discussion of the nature 
of spam, Harker outlined the different 
criteria that can be used for accepting 
and rejecting email. His approach differs 
from others in that he spends sendmail 
CPU cycles to get finer granularity in the 
decision to reject a message. He goes on 
to treat the problem of spammers send¬ 
ing their wares to internal aliases and 
mailing lists. 

The remainder of the presentation was 
devoted to detailed development of the 
sendmail rulesets necessary to implement 
these policies. He discussed the specific 
rulesets and databases needed, and how 
to test the results. His discussion and 
code are available at 
<http://www.harker.com/sendmail/anti-spam> 
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A Better E-mail Bouncer 

Richard J. Holland, Rockwell Collins 

Holland presented work that was moti¬ 
vated by corporate reorganization: how 
to handle email address namespace colli¬ 
sions in a constructive way. 

As email usage becomes more accessible 
to a wider spectrum of our society, fewer 
and fewer email users are able to parse 
the headers in a bounced message. 
Holland talked about his bouncer, imple¬ 
mented as a mail delivery agent, which 
provides a clearly written explanation of 
what happened and why when an email 
message bounces due to an address 
change. This helps the sender understand 
how to get a message through, helps the 
recipient get a message, and helps the 
postmaster by automating another por¬ 
tion of her workload. 

The bouncer was originally implemented 
as a simple filter. Because of the diversity 
in headers and issues related to envelope 
vs. header addresses, especially in the case 
of bcc: addresses, the bouncer was reim¬ 
plemented as a delivery agent. The 
bouncer, written in Perl, relinquishes its 
privilege and runs as “nobody.” Many of 
the aspects of bouncer operation are con¬ 
figurable, including the text of the 
explanatory text to be returned. A partic¬ 
ularly nice feature is the ability to send a 
reminder message to the recipients new 
address when mail of bulk, list, or junk 
precedence is received, reminding them 
to update their mailing list subscriptions 
with the new address. 

Holland concluded by discussing alterna¬ 
tives to the chosen implementation and 
future directions. Those interested in 
obtaining the bouncer should contact 
Holland at <holland@pobox.com>. 


INVITED TALKS TRACK 

So Now You Are the Project Manager 

William E. Howell, Glaxo Wellcome 
Inc. 

Summary by Bruce Alan Wynn 

Many technical experts find themselves 
gaining responsibility for planning and 
implementing successively larger projects 
until one day they realize that they have 
become a project manager. 

In this presentation, Howell offered help¬ 
ful advice on how you can succeed in this 
new role without the benefit of formal 
training in project management. 

Howells first suggestion is to find a men¬ 
tor, someone who has successfully man¬ 
aged projects for some time. Learn from 
that mentor not only what the steps are 
in managing a project, but also the rea¬ 
sons why those are the right steps. 

But, as Howell points out, a mentor is not 
always available. What do you do then? 
Howell presented a few tips on what you 
can do if you can’t find a mentor. 

For copies of the presentation slides, con¬ 
tact Marie Sands at 
<mms31901@glaxowellcome.com>; please 
include both your email and postal 
addresses. 


When UNIX Met Air Traffic Control 

Jim Reid, RTFM Ltd. 

Summary by Mike Wei 

Every once in a while we see reports of 
mishaps of the rapidly aging air traffic 
control (ATC) system in the United 
States. We have also seen reports that 
some developing countries have ATC sys¬ 
tems “several generations newer” than the 
US system. For most of the flying public, 
the ATC system is something near a total 
mystery on which our lives depend. As a 
pilot and a system administrator, I hope I 
can lift the shroud of mystery a little bit 
and help explain the ATC system Reid 
talked about, how UNIX handles such a 
mission-critical system, and how this sys¬ 
tem helps air traffic control. 

The primary purpose of air traffic con¬ 
trol is traffic separation, although it occa¬ 
sionally helps pilots navigate out of trou¬ 
ble. Government aviation authorities 
publish extensive and comprehensive reg¬ 
ulations on how aircraft should operate 
in the air and on the ground. Air traffic 
control is a massively complex system of 
computers, radar, controllers, and pilots 
that ensures proper traffic separation and 
flow. Human participants (i.e., con¬ 
trollers and pilots) are as essential as the 
computer and radar systems. 

Naturally, air traffic congestion happens 
near major airports, called “terminal 
areas.” In busy terminal areas, computer- 
connected radar systems provide con¬ 
trollers with realtime traffic situations in 
the sky. Each aircraft has a device called a 
transponder that encodes its identity in 
its radar replies, so the controllers know 
which aircraft is which on the computer 
screen. Computer software along with 
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traffic controllers ensure proper separa¬ 
tion and traffic flow by vectoring planes 
within the airspace to their destinations. 

Outside terminal areas, large planes usu¬ 
ally don’t fly anywhere they want. They 
follow certain routes, like highways in the 
sky. On-route traffic control centers con¬ 
trol traffic along those routes. Traffic sep¬ 
aration is usually ensured by altitude sep¬ 
aration or fairly large horizontal separa¬ 
tion. Some on-route centers have radar to 
help track the traffic. For areas without 
radar coverage, on-route centers rely on 
pilot position reports to track the traffic 
and usually give very large separation 
margins. 

This system worked fairly well for many 
years, until air travel reached record lev¬ 
els. Two things happened. First, some ter¬ 
minal areas became so congested that, 
during some parts of the day, the airspace 
just couldn’t hold any more traffic. 
Second, traffic among some terminal 
areas reached such a level that these on- 
route airspaces became almost as con¬ 
gested as terminal areas. 

A new kind of system was developed to 
address the new problems. This “slot allo¬ 
cation system” tries to predict what the 
sky will look like in the future, based on 
the flight plan filed by airliners. Based on 
the computer prediction, we can allocate 
“slots” in the sky for a particular flight, 
from one terminal area to another, 
including the on-route airspace in 
between. Every airline flight is required a 
flight plan, including departure time, 
estimated time on-route, cruising air¬ 
speed, planned route, destination, and 
alternate destination. With the flight 
plan, an airplane’s position in the sky is 
fairly predictable. 


This slot allocation system is very much 
like TCP congestion control in computer 
networking: when the network is con¬ 
gested, the best way to operate is to stop 
feeding new packets into it for a while. 

For the same reason it’s much better to 
delay some departures than to let planes 
take off and wait in the sky if the com¬ 
puter system predicts congestion some¬ 
time in the future. 

The Western European airspace, accord¬ 
ing to Reid, is the busiest airspace in the 
world. Instead of a single controlling 
authority, like the US Federal Aviation 
Authority, each country has its own avia¬ 
tion authorities. Before “Eurocontrol,” the 
agency Reid worked at last year, each 
country managed its airspace separately, 
and an airliner had to file a flight plan for 
each country it had to fly over along its 
route. This led to a chaotic situation 
when traffic volume increased. According 
to Reid, there was also a problem of ATC 
nepotism (i.e., a country favoring its own 
airliners when congestion occurred). 

The Eurocontrol agency has three UNIX- 
based systems that serve Western Europe. 
IFPS is a centralized flight plan submis¬ 
sion and distribution system, TACT is the 
realtime slot allocation system, and RPL 
is the repeat flight plan system. 

IFPS provides a single point of contact 
for all the flight plans in Western Europe. 
It eliminates the inconvenience of filing 
multiple flight plans. This is basically a 
mission-critical data entry/retrieval sys¬ 
tem. 

The TACT system provides slot allocation 
based on the flight plan information in 
the IFPS system. It provides slots that sat¬ 
isfy separation standards in the airspace 
above Western Europe. It controls when 
an airplane can take off and which slots 
in the sky it can fly through to its desti¬ 
nation. It keeps a “mental picture” of all 
the air traffic in the sky for all the 


moments into some future. RPL is the 
repeat flight plan system. Airlines tend to 
have the same flights repeatedly, and this 
system simplifies filing those flight plans. 
The RPL system is connected with the 
IFPS system and feeds it with those 
repeat flight plans. 

This must be an awesomely impressive 
system with equally impressive complexi¬ 
ty. According to Reid, it actually works. 

Ever since the adoption of the system, it 
has never failed. Furthermore, the 
increase in traffic delay is much less than 
the increase in traffic volume. Kudos for 

our European computer professionals! j 

i 

The slot allocation system does not pro- j 
vide the actual traffic separation. 

Realtime traffic separation must be based ! 
on actual position data obtained from ! 
radar or pilot position report, rather than j 
projected position data based on flight f 
plan. However, this slot allocation system 
is an invaluable tool to help the realtime 
traffic separation by avoiding congestion 
in the first place. 

Using UNIX in such a mission-critical 
system is quite pioneering in an ATC sys¬ 
tem. Most ATC systems in the US are still 
mainframe-based. The system is built on 
multiprocessor HP T90 servers, and the 
code is written in Ada. 

Like most of the mission-critical systems, 
operation of those UNIX systems has its 
idiosyncrasies. According to Reid, the sys¬ 
tem operation suffers organizational and 
procedural inefficiencies. However, some 
of them may well be the necessary price 
to pay for such a mission-critical system. 
The whole system is highly redundant; 
almost all equipment has a spare. The 
maintenance downtime is limited to one 
hour a month. Change control on the 
system is the strictest I’ve ever heard of. 

For new code releases, it has a test envi¬ 
ronment fed with real data, and there’s a 
dedicated test group that does nothing 
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but the testing. Any change to the pro¬ 
duction systems must be documented as 
a change request and approved by a 
change board, which meets once a week. 
Any kind of change, including fixing the 
sticky bit on /tnp, needs change board 
approval. Reid said that it took SA six 
weeks to fix the /tirp permissions on six 
machines because each one needed a 
change request and only one change a 
week is allowed on the production sys¬ 
tem. To minimize the chance of system 
failure, all nonessential service on the sys¬ 
tem is turned off, including NFS, NIS, 
and all other SA life-saving tools. This 
does add pain to SA’s daily life. 

This kind of process sounds bureaucratic, 
and it’s a far cry from a common UNIX 
SA’s habit. However, for this kind of sys¬ 
tem, it might be right to be overly conser¬ 
vative. At least when Reid flew to the 
LISA conference this year, he knew noth¬ 
ing bad would likely happen to 
Eurocontrol due to a system administra¬ 
tor’s mistake. 

Enterprise Backup and Recovery: 

Do You Need a Commercial Utility? 

W. Curtis Preston, Collective 
Technologies 

Summary by Bruce Alan Wynn 

Nearly every system administrator has 
been asked to back up filesystems. Even 
those who haven’t have probably been 
asked to recover a missing file that was 
inadvertently deleted or corrupted. How 
can a system administrator determine the 
best solution for a backup strategy? 

In this presentation, Preston presented an 
overview of standard utilities available on 
UNIX operating systems: which ones are 
common, which ones are OS-specific. He 
then explained the capabilities and limi¬ 
tations of each. In many cases, claims 
Preston, these “standard” utilities are suf¬ 
ficient for a site’s backup needs. 


For sites where these tools are insuffi¬ 
cient, Preston discussed many of the fea¬ 
tures available in commercial backup 
products. Because some features require 
special hardware, Preston described some 
of the current tape robots and media 
available. Once again, he iterated the 
capabilities and limitations of each. 

Copies of Preston’ presentation are avail¬ 
able upon request; Preston can be 
reached at <curtis@colltech.com>. 

A Technologist Looks at Management 

Steve Johnson, Transmeta Corp. 

Summary by Bruce Alan Wynn 

Employees often view their management 
structure as a bad yet necessary thing. 
Johnson has worked in the technical 
arena for years, but has also had the 
opportunity to manage research and 
development teams in a number of com¬ 
panies. In this presentation, he offered his 
insight into methods that will smooth the 
relationship between employees and 
managers. 

Johnson began by postulating that both 
employees and managers have a picture 
of what the manager-employee relation¬ 
ship should look like, but it is seldom a 
shared picture. He further postulated that 
a great deal of the disconnect is a result 
of personality and communication styles 
rather than job title. 

Johnson loosely categorized people as 
either thinkers, feelers, or act-ers. A 
thinker focuses on analyzing and under¬ 
standing; a feeler focuses on meeting the 
needs of others; an act-er focuses on 
activity and accomplishment. 


These differences in values, combined 
with our tendency to presume others 
think as we do, cause a breakdown in 
communication that leads to many of the 
traditional employee-manager relation¬ 
ship problems. 


After making this point, Johnson suggest¬ 
ed that technical people who are given 
the opportunity to move into manage¬ 
ment first examine closely what the job 
entails: it’s not about power and author¬ 
ity; it’s about meeting business needs. He 
suggested a number of publications for 
additional information on this topic. 


Steve Johnson can be reached at 
<scj@transmeta.com>. 


IPv6 Deployment on the 6bone 

Bob Fink, Lawrence Berkeley National 
Laboratory 

Summary by Mike Wei 

We all know that IPv6 is the future of the 
Internet; there’s simply no alternative to 
support the explosive growth of the 
Internet. However, despite years of talk¬ 
ing, we see little IPv6 deployment. 
According to Fink, the adaptation and 
deployment of IPv6 is currently well 
under way, and it’s heading in the right 
direction. 

An experimental IPv6 network, named 
6bone, was created to link up early IPv6 
adopters. It also serves as a test bed to 
gain operational experiences with IPv6. 
Because most of the machines on the 
6bone also run regular IPv4, it provides 
an environment to gain experience in 
IPv4 to v6 transition. 

The 6bone is truly a global network that 
links up 29 countries. Most of the long 
haul links are actually IPv6 traffic tun¬ 
nelled through the existing IPv4 Internet. 
This strategy allows 6bone to expand 
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anywhere that has an Internet connection 
for almost no cost. On the 6bone net¬ 
work, there are some “islands” of network 
that run IPv6 natively on top of the phys¬ 
ical network. 

An important milestone was achieved in 
IPv6 deployment when Cisco, along with 
other major router companies, commit¬ 
ted to IPv6. According to Fink, IPv6 will 
be supported by routers in the very near 
future, if it’s not already supported. In 
addition, we will start to see IPv6 support 
in major OS releases. 

A typical host on the 6bone runs two IP 
stacks, the traditional v4 stack and the 
IPv6 stack. The IPv6 stack can run 
natively on top of the MAC layer if the 
local network supports v6, or it can tun¬ 
nel through IPv4. The v6 stack will be 
automatically used if the machine talks to 
another v6 host. An important compo¬ 
nent of the 6bone network will be the 
new DNS that supports IPv6 addresses. 
The new DNS supports AAAA record 
(quad-A record, because a v6 address is 
four times the length of a v4 address). If a 
v6 host queries the new DNS server for 
another v6 host, an AAAA record will be 
returned. Because the new DNS simply 
maps a fully qualified domain name to an 
IP address (v4 or v6), the DNS server 
itself doesn’t have to sit on a v6 network. 
It will be perfectly normal for a dual¬ 
stack v6/v4 host to query a DNS server 
on the v4 network, getting a v6 address, 
and talk to the v6 host in IPv6. 

The key to the success of IPv6 deploy¬ 
ment is smooth transition. The transition 
should be so smooth that a regular user 
should never know when the IPv6 has 
arrived. Given the fact that the IPv4 net¬ 
work is so far reaching throughout the 


world, IPv6 and v4 will coexist for a very 
long time; the transition to IPv6 from v4 
will be gradual. Routers will be the first 
ones that have IPv6 capabilities. Just like 
the 6bone, an IPv6 backbone can be built 
by tunnelling v6 traffic through the exist¬ 
ing v4 network or run v6 natively on the 
physical network when two neighboring 
routers both support v6. Because v6 is 
just another network layer protocol, it 
can run side by side with IPv4 on the 
same physical wire without conflict, like 
IP and IPX can run together on the same 
Ethernet. This means that we do not have 
to make a choice between v6 and v4; we 
can simply run both of them during the 
transition period. IP hosts will gradually 
become IPv6 capable when the new OS 
versions support it. During the transi¬ 
tion, those IPv6 hosts will have dual IP 
stacks so they can talk to both v4 and v6 
hosts. Nobody knows how long this 
“coexist” will last, but it will surely last 
for years. When the majority of the hosts 
on the Internet are doing v6, some of the 
hosts might choose to be v6 only. One by 
one, the v4 hosts will fade away from the 
Internet. 

Will that ever happen? The answer is yes. 
In the next decade, the IPv4 address will 
be so hard to obtain that IPv6 will be a 
very viable and attractive choice. We 
haven’t seen that yet, but based on the 
current Internet growth, it will happen. 

The IPv6 addressing scheme is another 
topic Fink talked about in the seminar. 
IPv6 has a 128 bit address space, which 
allows thousands of addresses per square 


foot if evenly spread on the earth’s sur¬ 
face. How to make use of this address 
space in a highly scalable way is a big 
challenge. IPv4 suffers the problem of an 
explosive number of routing entries, and 
this problem arises years before the 
exhaustion of IPv4 addresses. To address 
this problem and to allow decades of 
future expansions, IPv6 uses an aggrega¬ 
tion-based addressing scheme. 

3bits 13bits 32bits 16bits 64 bits 

001 TLA NLA SLA Interface ID 

public topology site local machine 

topology 

The best analogy of this aggregation- 
based addressing is the telephone number | 
system. We have ten-digit phone numbers j 
in US and Canada, with a three-digit area j 
code, three-digit exchange code, and the j 
last four digits for individual telephone 
lines. 

The first three bits are 001. In the great 
tradition of TCP/IP, other combinations 
are reserved for future use, in case one 
day we have an interplanetary communi¬ 
cation need that requires a different 
addressing scheme. The 13-bit TLAs are 
top-level aggregators, designed to be 
given to long-haul providers and big tel¬ 
cos that run backbone service. The 32-bit 
NLAs are next-level aggregators for vari¬ 
ous levels of ISPs. It can be further subdi¬ 
vided to several levels of NLAs. The 16- 
bit SLAs are for site topologies. (It’s like 
getting a class A IPv4 address and use 16- 
bit for network address.) The machine 
interface ID is 64 bits. 

An important feature of IPv6 is autocon¬ 
figuration, in which a host can figure out 
its own IPv6 address automatically. The 
64-bit interface ID is designed so that the 
host can use its data link layer interface 
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address as the host portion of the IPv6 
address. Ethernet uses a 48-bit address, 
and it seems adequate for globally unique 
addresses. Reserving 64 bits for the local 
machine shall accommodate any future 
address method used by future physical 
networks. 

Aggregation-based addressing is a big 
departure from the current IPv4 address¬ 
ing. Although IPv4 has three classes of 
addresses, it’s not a hierarchical address¬ 
ing scheme. In IPv4 (at least before the 
CIDR days), all the network’s addresses 
were created equal, which means they 
could all be independently routed to any 
locations they chose to be. This caused 
the routing entry explosion problem 
when the Internet grew. Classless Inter 
Domain Routing (CIDR) was introduced 
as a stopgap measure to address this 
urgent problem by introducing some 
hierarchy in the IPv4 address space. IPv6 
is designed at the beginning with a hier¬ 
archical scheme. By limiting the number 
of bits for each aggregator, there is an 
upper limit to the number of routing 
entries that a router needs to handle. For 
example, a router at a long-haul provider 
needs only to look at the 13-bit TLA por¬ 
tion of the address, limiting the possible 
number of routing entries to 2 U . 

Another advantage of a hierarchical- 
based addressing system is that address 
allocation can be delegated in a hierarchi¬ 
cal manner. The success of DNS teaches 
us the important lesson that delegation of 
address allocation authority is a key to 
scalability. 

There’s a price to pay to use a hierarchical 
addressing system. When a site changes 
its providers, all the IP addresses need to 


be changed. We already experience the 
same kind of issue in IPv4 when we use 
CIDR address blocks. IPv6 tries to make 
address changes as painless as possible, to 
have a host autoconfigure itself. The host 
will use its MAC layer address as the 
lower portion of its IPv6 address and use 
a Network Discovery protocol to find out 
the upper portion of the address (routing 
prefixes). The whole site can be renum¬ 
bered by simply rebooting all the hosts 
without any human intervention. 

There are still lots of problems to be dis¬ 
covered and addressed in IPv6. That’s 
exactly what the 6bone is built for. IPv6 is 
the future of the Internet, and the transi¬ 
tion to IPv6 will start in the near future. 

More information on 6bone can be 
found on <http://www.6bone.net> 

Joint Session 

Panel: Is System Administration a Dead- 
End Career? 

Moderator: Celeste Stokely, Stokely 
Consulting 

Panelists: Ruth Milner, NRAO; Hal 
Pomeranz, Deer Run Associates; 
Wendy Nather, Swiss Bank Warburg; 
Bill Howell, Glaxo Wellcome Inc. 

Summary by Carolyn M. Hennings 

Ruth Milner opened the discussion by 
responding to the question with, “It 
depends.” She went on to explain that it is 
necessary for everyone to define “system 
administration” and “dead-end career” to 
answer this question for themselves. In 
some organizations, “system administra¬ 
tion” leaves no room for growth. 

However, Ruth pointed out that if people 
enjoy what they do, then maybe it should 
not be considered a “dead-end.” 

Hal Pomeranz outlined the typical career 
progression for system administrators. 

He described the first three years in the 


career field as a time of learning while 
receiving significant direction from more 
senior administrators. During the third 
through fifth years of practicing system 
administration, Hal suggested that even 
more learning takes place as the individ¬ 
ual works with a greater degree of auton¬ 
omy. Hal observed that people with more 
than five years of experience are not 
learning as much as they were, but are 
more focused on producing results as 
well as mentoring and directing others. 
Hal commented that many organizations 
move these senior people into manage¬ 
ment positions and wondered how tech¬ 
nical tracks might work. 


Wendy Nather discussed the question 
from the angle of recruiting. Those hiring 
system administrators are looking for 
people who have dealt with a large num¬ 
ber of problems as well as a variety of 
problems. She pointed out that being a 
system administrator is a good spring¬ 
board to other career paths. Wendy out¬ 
lined some of the characteristics of good 
system administrators that are beneficial 
in other career areas: a positive attitude, 
social skills, open-mindedness, and flexi¬ 
bility. 

Bill Howell examined the financial 
prospects for system administrators. He 
commented that there will always be a 
need for system administrators. However, 
industry may be unable and unwilling to 
continue to pay high salaries for them, 
and salary increases may begin to be lim¬ 
ited to “cost of living” increases. Bill sug¬ 
gested that growth in personal income 
and increases in standard of living are the 
results of career advancement. If salaries 
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do become more restricted in the future, 
system administration may become a 
dead-end career. 

Celeste then opened up the floor for 
questions and discussion. One partici¬ 
pant asked about other career options if 
one was not interested in pursuing the 
managerial or consultant path. The panel 
suggested that specializing in an area 
such as network or security administra¬ 
tion would be appropriate. Discussion 
ranged among topics such as motivation 
for changing positions, how the size of 
the managed environment affects oppor¬ 
tunities and working relationships, the 
impact of Windows NT on UNIX admin¬ 
istrator’s careers, how an administrator’s 
relationship with management changes 
with career advancement, and the impor¬ 
tance of promoting system administra¬ 
tion as a profession. 


BOFs 

Summaries by Carolyn M. Hennings 

Keeping a Local SAGE Group Active 

This BOF at LISA ’96 and SANS ’97 
inspired me to start a group in Chicago. 
Chigrp’s initial meeting was in early 
October, and I was anxious to announce 
our existence. General suggestions for 
getting a group started and keeping one 
alive were shared by attendees. If you 
want more information on how to start a 
group, see <http://www.usenix.org/sage/locals/>. 


Documentation Sucks! 

As system administrators, we all know 
how important documentation is, but we 
hate to write it. This BOF explored some 
of the reasons we don’t like to write doc¬ 
umentation, elements of good documen¬ 
tation, and what we can do personally to 
improve our efforts in this area. About 
50 people attended the BOF. Some pro¬ 
fessional technical writers participated in 
the BOF and were interested in the 
approach sys admins were taking in their 
struggle to write documentation. 
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SAG [news & features 


Worth Repeating 



Tina Darmohray, editor of 
SAGE News & Features, is a 
consultant in the area of 
Internet firewalls and net¬ 
work connections, and fre¬ 
quently gives tutorials on 
those subjects. She was a 
founding member of SAGE. 


<tmd@usenix.org> 
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rhere were a lot of things to see and do 
it the recent LISA conference in San 
Diego. One of the highlights for me was 
he short, impromptu speech that Paul 
/ixie gave as he accepted the annual 
>AGE Outstanding Achievement Award. I 
vish I could think up such “right on,” 
leartfelt words on the spot. He did, and 
hey really went to the heart of one of the 
'easons why it’s so cool to be a part of 
his technical community. The award 
xads: 

SAGE 

The 1997 Outstanding Achievement 
Award 

Presented to Paul Vixie 
for his work on DNS and BIND 
and for his leadership in 
opposing inappropriate use of the 
Internet 

[’ve included them here for those of you 
who didn’t have the opportunity to hear 
Paul’s words live. But even if you caught 
his speech, I think his message is worth 
repeating. 

My first reaction on being told of this 
was that you guys are really scraping 
the bottom of the barrel now! 

Pause for laughter to die down. 

I guess I’ve got a couple of remarks to 
make. 


or somewhere else far away, and he was 
remarking on how it was amazing him 
to walk through the halls of the confer¬ 
ence and see all of the people that he 
had been hearing about and reading 
articles from on USENET over the 
years. And I got to talking to him about 
where I was from, and what I did, and I 
told him that I had just started at DEC 
Palo Alto. Now, he was sitting on one 
side of me and my badge was hanging 
on the other side of me, and he said, 
“Oh! Isn’t that where Vixie hangs out?” 

Paul imitated the original delivery of his 
last name, which was with some hint of 
disdain or incredulity. 

And I said, u Uh huh.” 

Pause for laughter to die down. 

And certainly, on one hand, I was very 
glad to have been noticed (we all like 
attention), but I was a little bit con¬ 
cerned at his tone of voice, in that per¬ 
haps I had been even more vitriolic 
than I had intended to be on the vari¬ 
ous mailing lists and newsgroups 
where he might have noticed me. And 
that sort of gave me my first inkling 
that someday I was going to be a well- 
known person, and I wondered what 
that would be like. 



One is that at my very first USENIX, I 
was sitting in the very first tutorial and 
the fellow next to me was from Alaska, 


Paul Vixie accepts congratulations at LISA from 
SAGE President Hal Miller. 


What I’ve discovered is that it’s a little 
bit like parenting: when you’re a kid, 
you think your parents know every¬ 
thing and have super powers, and that 
someday you’re going to grow up and 
you’ll know everything, too. Then you 
get to be a parent and discover that 
your parents were shining you on; they 
didn’t have a clue! So here I am! 

Applause and laughter by the attendees 
and a pause before Paul continues, with 
a more serious demeanor. 

I would not be here if not for the kind 
attentions of Rick Adams and Brian 
Reid, both of whom thought that I 
was worth teaching at various times. 
And if their work can be an example 
to me it will be because I have found 
other people who were worth teaching 
and I hope that that in turn will be an 
example to all of you. 

The way that this industry works is not 
that we all go to school. Some folks 
have been lucky enough to work with 
Evi and other really great instructors. 
But, for the most part, we’re in this for 
fun and we’re trying to learn and it’s 
only to the extent that other people are 
willing to work with us and tell us the 
clues so we can prosper and succeed 
and get better at what we do. So if 
you’re not mentoring somebody, you 
should start thinking about how you’re 
going to start doing that. 

I thank you for the award. 

Postscript from Paul: At my first 
USENIX conference, I noticed Henry 
Spencer’s name tag and the man who 
went with it and wondered, as described 
in my award speech, what it must be like 
to write software that everybody every¬ 
where runs. Since then, I have inherited 
and written some well-known software. 
At this conference, I spoke to Henry. We 
talked about memory leaks in C News 
and BIND, and now I know the answer to 
my earlier question. I am very honored to 
have been recognized by my peers. 
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( President's Letter ) 



<halm@usenix.org> 


One of the issues on my mind recently is 
the relationship between SAGE and vari¬ 
ous vendors. Although this hasn’t become 
a very high priority, its still something 
we have to deal with and will continue to 
deal with. Here, then, are some thoughts 
on the matter. I hope someone will pon¬ 
der this more thoroughly and write a 
proposal on what we ought to do. 

As I often do, I broke this down into a 
series of questions, then put some 
answers together. Everyone has their own 
style. My questions this time are: 

■ What is the problem? 

■ What is the current “relationship”? 

■ What do we want the relationship to 
be? 

■ What do we not want the relationship 
to be? 


What Is the Problem? 

It’s us, or some of us anyway. We as a 
guild have been conscientiously avoiding 
the “appearance of impropriety” with 
regard to tying ourselves to any vendor to 
the detriment of others. We as individu¬ 
als often earn our livelihood from those 
vendors. The best interests of our 
employers may sometimes conflict with 
“the greater good” of society. Fortunately, 
that conflict doesn’t seem to be very seri¬ 
ous yet. As our profession continues to 
grow and mature and as vendors contin¬ 
ue to jump on the bandwagon (“Oh wow, 
thousands of potential buyers, and 
they’re the ones who actually decide what 
to buy!”), I expect this to become more 
difficult to manage. 

The problem, then, is how to reconcile 
the conflicting interests of the individual 
vendors that supply our industry with 
those of the community as a whole. 

What Is the Current “Relationship”? 

Things have been, overall, pretty good 
thus far. We have sponsoring members, 
an excellent vendor show at LISA, hospi¬ 
tality suites, T-shirts, mugs and toys, and 
some level of influence on the engineers 
at those vendors who are building the 
products we will be purchasing (partly 


SAGE, the System Administrators Guild, is a 
Special Technical Group within USENIX. It is 
organized to advance the status of computer 
system administration as a profession, 
establish standards of professional excellence 
and recognize those who attain them, develop 
guidelines for improving the technical and 
managerial capabilities of members of the 
profession, and promote activities that advance 
the state of the art or the community. 

To achieve its mission SAGE may: 

Sponsor technical conferences and workshops; 

Publish a newsletter, and/or professional 
short topics series; 


Develop curriculum recommendations and 
support education endeavors; 

Develop a process for the certification of 
professional system administrators; 

Recognize system administrators who are 
outstanding or are otherwise deserving of 
recognition for service to the professional 
community; 

Speak for the concerns of members to the 
media and make public statements on issues 
related to system administration; 

Promote and support the creation and activities 
of regional or local professional system 
administrators. 


because those engineers are “us” too). 
However, there are also some negatives. If 
we are seen to favor one vendor over oth¬ 
ers, we are opening ourselves to various 
problems. We have seen in a number of 
instances that BOFs at LISA can degener¬ 
ate into sales pitches if we’re not careful. 
We are beginning to see a proliferation of 
separate “certification” programs, with no 
telling where that may lead. 

There have always been a few “very big” 
vendors in our industry and generally 
lots of “wish we were big” vendors. My 
view of where SAGE fits into the commu¬ 
nity does not include helping make any¬ 
one profitable, but to help vendors ensure 
their products meet our needs, for the 
obvious self-serving interest. 

What Do We Want 
the Relationship to Be? 

One of the primary motivating factors 
in my interest in SAGE has always been 
the gain we all get from pooling our 
resources. The more we share our pre¬ 
cious time and effort, the more we all 
win. I see this as the biggest potential 
value for SAGE members in future rela¬ 
tions with our vendor force. We as indi¬ 
viduals and as a guild ought to be inti¬ 
mately involved with vendors on future 
direction, bug reporting, design issues, 
and so forth. We should be the place ven¬ 
dors turn when they want to know which 


SAGE STG EXECUTIVE COMMITTEE 

President: 

Hal Miller <halm@usenix.org> 

Secretary: 

Tim Gassaway <gassaway@usenix.org> 

Treasurer: 

Barb Dijker <barb@usenix.org> 

Members: 

Helen Harrison <helen@usenix.org> 

Amy Kreiling <amy@usenix.org> 

Kim Trudel <kim@mit.edu> 

Pat Wilson <paw@usenix.org> 


32 


Vol. 23, No. 1 jlogin: 









products or features are of value and 
which are merely marketing hype, useless 
to those of us stuck trying to implement 
them. 

I want vendors to “bring” SAGE with 
them when they visit their client sites. 
They see many of our “potential” mem¬ 
bers, particularly those who don’t know 
we exist and whom we have (thus far) 
not reached. I want more vendors to join 
as sponsoring members. And, of course, I 
like the toys they supply us with.... 

What Do We Not Want 
the Relationship to Be? 

Clearly, I don’t want to see us align too 
strongly with any one vendor in any 
given field. We border on that occasional¬ 
ly as it is, which makes me think we need 
to consider taking steps to improve com¬ 
petition, but that’s not our role either. I 
was a little upset with a couple of vendors 
who put on at the last LISA “BOF”s that 
were nothing more than sales presenta¬ 
tions. I most definitely don’t want any 
vendor (or series of vendors) influencing 
SAGE’s direction to any significant 
degree, even though I recognize that 
every vendor is likely to influence us to 
some degree. 


What Can You Do? 

Think about how our vendors can meet 
their needs without doing so at the 
expense of SAGE and how SAGE can 
continue to press for improvements in 
computer systems and networks without 
doing so at the expense of any given ven¬ 
dor. How can we define the roles, and 
how do we ensure continued good rela¬ 
tions? 


New Editor for Short 
Topics Series 



SAGE is pleased to 
announce that William 
N. LeFebvre is now 
Editor for the publica¬ 
tion series, “Short 
Topics in System 
Administration.” This 
series of booklets is 
intended to present topics in a thorough, 
refereed fashion that are of immediate 
use to the growing community of system 
and network administrators. 


Bill has been a tutorial speaker, program 
committee member, session chair, author, 
speaker, and guru at various USENIX and 
SAGE events since 1992. He is a pub¬ 
lished author on UNIX topics and has 15 
years of experience with UNIX systems, 


most of them as a system administrator. 
As editor, he will be reponsible for coor¬ 
dinating new content for the series; orga¬ 
nizing revised editions of existing book¬ 
lets; and acting as liaison between 
authors, readers, and the USENIX staff. 

“I consider it an honor to be appointed 
to this position,” Bill says, “I will endeav¬ 
or to make the SAGE series an indispens¬ 
able part of every system administrator's 
book collection.” 


Forthcoming in early 1998 are two new 
booklets in the series on system adminis¬ 
trator education and on hiring and inter¬ 
view practices. A booklet on legal issues 
for system administrators will follow. If 
you have a proposal for a new topic that 
you’d like to develop into a booklet, 
please contact Bill LeFebvre at 
<wnl@usenix.org>. 
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( Auditing : The Ugly Duckling of Computers ) 

Auditing is an often overlooked portion of system administration, both in the 
UNIX and Windows NT world. At least 80% (maybe 95%) of the sites I work 
with do not utilize the auditing functionality of their systems. In this article I 
discuss what I consider the minimal amount of auditing that would be of bene¬ 
fit in troubleshooting or security tracking. I then give specific recommendations 
for Solaris 2.X and Windows NT 4.0. 

Most people I talk with cite “resources,” both human and computer, as the reason they 
have not yet implemented auditing. They say that computer resource usage, such as 
disk, processor, and memory, is extensive, and that the time resource for their staff to 
maintain the system as well as review the data is not worth the hassle. I understand this 
mindset. My first experience (1991) with C2 auditing on SunOS was daunting. The log 
files filled up so fast that I could not maintain them adequately, never mind that I never 
got a chance actually to look through the logs for information. After about two weeks, I 
just shut it off and wrote the experience off as “proper motivation, but ignorance of 
reality” The following is a good introduction into practical settings for auditing, with 
specifics for Windows NT 4.0 and Solaris 2.X. 


Minimal Auditing Requirements 

With all the reasons we have for why we don’t and why we should audit, there needs to 
be a starting place. Many people ask me, “What should I be auditing?” To answer this, I 
have compiled a general list of “auditing categories” that I feel is a good minimal start¬ 
ing point: 


■ all successful and unsuccessful login and logout events 

■ all modifications to system specific files (config files, system binaries, and libraries) 

■ all administrative actions (user adds, host changes, password changes, etc.) 

■ all system type events (reboots, eeprom changes, etc.) 

This set gives you a very good, though not complete, picture of your system at any 
given point in time. You will find it invaluable in troubleshooting, as well as incident 
handling. 


Setting Up Auditing: The Specifics for Windows NT 

First you must “enable” auditing. There are two different types of auditing in Windows 
NT: system level and file/directory level. The “system level” is what I am most con¬ 
cerned with. To set system level auditing, open the “User Manager” tool. While in the 
User Manager select “Policies->Audit->Audit These Events.” Then set the following 
policy: 

Logon and Logoff: success and failure 


File and Object Access: none (see Auditing Files and Directories) 
Use of User Rights: none 

User and Group Management: success and failure 


Security Policy Changes: success and failure 
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Restart, Shutdown, and System: success and failure 
Process Tracking: none 

Auditing Files and Directories 

Auditing files and directories allows you to track their usage. For a particular file or 
directory, you can specify which groups or users and which actions to audit. You can 
audit both successful and failed actions. To audit files and directories, you must set the 
audit policy to audit file and object access. You can select the following file and directo¬ 
ry events to audit: 

Read: display of filenames, attributes, permissions, contents, and owner 

Write: creation of subdirectories and files, changes to attributes, change in contents, 
and display of permissions and owner 

Execute: display of attributes, permissions, and owner; execution of file and changing 
to subdirectories 

Delete: deletion of file or directory 
Change Permissions: changes to permissions 
Take Ownership: changes to ownership 

You will have to determine which directories and files are to be audited on your system, 
but a good option is to audit “Write” attempts to files in the %systemroot\system32 
folder. To do this, you would select the “Properties” option on the folder, then 
“Security->Auditing->Add.” Then add “Everyone” and select “Write : success and fail¬ 
ure,” do “replace on existing files,” do not “replace on existing subdirectories.” 

Viewing the Audit Events 

You can use the “Event Viewer” for viewing audit events, or there are several third party 
reporting packages available. I am investigating the EventLog module for Win32 Perl. I 
have heard a lot of good comments on it, but have not used it extensively. 

Setting Up Auditing: The Specifics for Solaris 2.X 

The auditing package that comes with Solaris is part of the BSM (Basic Security 
Module) package. The audit daemon auditd is the process that performs the auditing 
on Solaris systems. It is started by default if the /etc/security/audit_startup file 
exists. The actions that can be audited are defined in the /etc/security/audit_event 
file. This file can be customized, but it is very in-depth and beyond the scope of this 
article (the answerbook has a very good description of the whole process and files 
involved). 

Audit flags indicate which classes of events to audit. Systemwide defaults are listed in 
/etc/security/audit_control. This file is very important and is the basis for the rest 
of the discussion. This file is similar to the “User Manager->Polices->Audit” setup in 
NT; it controls will be audited on the system and what will not. Set up improperly, and 
you will either have too much information or too little. A man on audit_classes (4) 
will give you a large amount of information. In standing with my initial recommenda¬ 
tions, here is an audit_control file to start with: 

dir:/etc/security/audit 
flags:lo,ad,-fm,-fc,-nt 
naflags:lo,ad 
minfree:10 


You will have to determine 
which directories and files 
are to be audited on your 
system, but a good option 
is to audit "Write” 
attempts to files in the 
%systemroot\system32 
folder. 
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Audit maintenance on 
Solaris has a steep learn¬ 
ing curve, but it flattens 
out pretty quickly. The 
best documentation is in 
the answerbook. 


Let’s see what this means. The first line defines the directory for the audit files to be 
placed. This location must have adequate space; if it fills up it will lock you out.[ 1] You 
can have more than one dir flag in the file, and they will be used in the order specified. 
The second line is for events attributable to a user, and tells us the following: (see the 
audit_event file for list of actions that fall into a class): 

lo - all login and logout events 

ad - all administrative actions 

-fm - all failed change of object attributes (chmod, flock, etc.) 

-fc - all failed creation of objects 

-nt - all failed Network events (This may be noisy) 

The third line is for events that are not attributable to a specific user. The fourth line 
tells us the minimum free in the dir files before we get a warning message from the 
audit system. The audit -s command will cause the auditd to reread this file after 
editing. 

The other file of interest is the /etc/security/audit_user. This file allows more spe¬ 
cific auditing of individual users. If specified, the flags in this file are combined with the 
global flags in audit_control to provide a more granular auditing ability. 

Keeping Solaris Audit Files Manageable 

To keep audit file manageable, a cron job can be set up to periodically rotate the audit 
files. The audit -n command will checkpoint the logs. This process closes the current 
audit log and opens another. Then you can process the just closed audit file. Figure 1 is 
a rudimentary script that will process the just closed audit log. Figure 2 is a script to 
store and rotate audit logs created during the auditreduce portion, a simple modifica¬ 
tion of the newsyslog script. 

Audit maintenance on Solaris has a steep learning curve, but it flattens out pretty 
quickly. The best documentation is in the answerbook. It is specific and very descrip¬ 
tive. I recommend that anyone not strongly familiar with Solaris auditing read it before 
you implement the system. 

Conclusion 

Now that my primary job is helping those unfortunate individuals or sites with security 
incidents, I see the errors in not taking the time in 1991 to “finish the job.” In an inci¬ 
dent, if you don’t have good logs (i.e., auditing), you’d better have good luck. The 
chances of figuring out what happened without good auditing are few and far between. 
If you take one thing from this article, make it this: Take the time, learn your systems, 
and set up auditing that is adequate and appropriate for your systems. 

In the next issue, I will discuss central management of UNIX and NT audit files. 

Note 

[1] If all audit directories fill, either the “cnt” policy must be enabled, or an “audit” 
account that is not subject to auditable events must exist. See the “Administering 
Auditing” in the Basic Security Module Answerbook. 
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Figure 1: A rudimentary script 

#!/bin/sh 

# Checkpoint the logs so we can reduce them 
/usr/sbin/audit -n 

# Setup path to search for modified files in, - says to ignore this 

# file or directory 

# excluding /dev/might be too permissive, but it generates a lot of 

# "noise" otherwise 

srch_path="/usr/sbin, /sbin,-/etc/uucp,-/etc/syslog.pid, /etc, /usr/bin, 
/usr/li b, /usr/openwin/lib, /usr/openwin/bin, -/dev, -/devices, /kernel" 

# get the hostname 
host='uname -n' 

# Want to be able to clobber /tmp/foo if already exists 
unset noclobber 

# Setup the header in the file echo 

M $host Login/out event" > /tmp/foo 
echo " ■ » /tnp/foo 

echo " " » /tmp/foo 

# Use auditreduce to get the information, and praudit to clean it 

# up. Will give us a listing of all login/logout events, 
/usr/sbin/auditreduce -C -c lo | /usr/sbin/praudit » /tnp/foo 

echo "sssssssssssssassssssssssssssassssssasssssssssasss" » /tlip/fOO 

echo "$host Prom event" » /tmp/foo 
echo “ " » /tnp/foo 

echo " " » /tmp/foo 

# Will give all events associated with PROM events 
/usr/sbin/auditreduce -C -m AUE_EXITPROM | /usr/sbin/praudit » 

/tnp/foo 

echo "$host Boot event" » /tmp/foo 
echo " " » /tnp/foo 

echo " " » /tnp/foo 

# Will list all events associated with system boot 
/usr/sbin/auditreduce -C -m AUEJSYSTEMBOOT | /usr/sbin/praudit » 

/tmp/foo 

echo "$host File Mod event" » /tnp/foo 
echo " " » /tmp/foo 

echo 11 " » /tnp/foo 

#Will list all File modification events for file in $srch w path 
/usr/sbin/auditreduce -C -c fm -o path= $srctL_path | /usr/sbin 
/praudit | grep ^path | sort | uniq» /tnp/foo 

echo "$host Admin event" » /tnp/foo 
echo " " » /tnp/foo 

echo " " » /tnp/foo 

echo " " » /tnp/foo 

# Will list all administrative events 

/usr/sbin/auditreduce -C -c ad -o path=$srch_path | /usr/sbin 
/praudit » /tnp/foo 

# Mail the file to the person watching audit logs 
/bin/mail logwatcher@audithost.ntsinc.com < /tmp/foo 
rm /tnp/foo 
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Figure 2: A simple modification of newsyslog script 



<jsellens@uunet.ca> 


#!/bin/sh 

# location of audit log files 
cd /etc/security/audit 

# Tar all files matching the pattern, not Y2K compliant :) 
/usr/sbin/tar cf tarfile 19*.199* 

# then remove the individual file to save space 
/bin/rm 19*.199* 

LOG=tarfile 

test -f $LOG. Z. 6 && mv $LOG.Z.6 $L0G.Z.7 

test -f $LOG. Z. 5 ScSc mv $L0G.Z.5 $L0G.Z.6 

test -f $LOG.Z.4 && mv $L0G.Z.4 $L0G.Z.5 

test -f $LOG.Z.3 && mv $LOG.Z.3 $LOG.Z.4 

test -f $LOG.Z.2 && mv $L0G.Z.2 $L0G.Z.3 

test -f $LOG.Z.1 && mv $LOG.Z.l $L0G.Z.2 

test -f $LOG.Z. 0 ScSc mv $LOG.Z.O $LOG.Z.l 

mv $LOG.Z $LOG.Z.0 

# compress the new tar file to save space 
/usr/bin/compress tarfile 
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( On Reliability - What About Yourself? ) 

In past articles on reliability, I’ve talked about general principles of reliability, 
computing hardware, networking, and some aspects of system administration. 
Most of those things are really quite tangible - if you can't put your hands on 
them physically, you can at least copy them to a printer or a tape drive and 
hold them in your hands that way. 

Since I wrote the last article (for the December issue, publishing deadlines being what 
they are), I’ve been to the 11th LISA conference in San Diego, where we spent a lot of 
time (more than usual) talking about management, motivation, and people issues. 

Since returning home, I’ve found myself doing some reading on management and peo¬ 
ple and thinking more about the people issues that we face in our jobs (and other activ¬ 
ities). And I’ve spent a heck of a lot of time in meetings, working with people, and 
thinking about motivation, coordination, and how people can really enjoy their work. 

So I find myself here with my laptop on my daily commute on the intercity bus and 
with the Christmas holidays and a new year looming up before me, composing a relia¬ 
bility article with a different flavor this month. Vm compelled to consider, from a pure¬ 
ly amateur point of view, personal reliability. By that I mean to consider how we inter¬ 
act with our co-workers, vendors, customers, and, to a lesser extent, friends and fami¬ 
lies. How does one act “reliably”? 

How is this relevant to system administrators and computing professionals in general? 
How does this help to make our computer systems and networks run better and more 
effectively? System administration is very closely tied to personal interaction, with indi¬ 
viduals and with groups, and sometimes with people that you will never see or talk to 
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directly. I’ll try to give a few examples of why I think that is the case and why reliability 
and trust are important. 

System administration is a service activity - we supply the computing resources so that 
other people can do their work (or play). We solve problems for people, we design sys¬ 
tems and software to serve people, and we help people learn to accomplish their com¬ 
puting tasks in the most effective ways. Any time we install a new command, send out a 
notice or advisory message, or answer the phone on the help desk, the underlying end 
product is (almost always) a service for some person or group. When we take a system 
down for maintenance, submit a request for more funding for more equipment, design 
a mission-critical computing environment, start fixing a computer or network problem, 
or propose a solution to suit someone’s needs, we’re asking for trust: trust that we are 
using good judgment, trust that we are knowledgeable and competent, and trust that 
our intentions are good. In short (and I’m sure you’ve been waiting for this), we are 
asking others to rely on us. And that’s where reliability comes into things this time 
around. 

Why is it important to be reliable? Quite simply, if we are to call ourselves “profession¬ 
als,” we must rely on our reputations, and the most important part of a (positive) repu¬ 
tation is the trust that people can place in us, our judgment, and our abilities. If we can¬ 
not be relied upon, all of our experience and abilities will be far less valuable to our cus¬ 
tomers and co-workers. The ability of others to rely on us is the foundation of the value 
that we bring to the profession of system administration. 

How do you demonstrate your reliability? How do you earn the trust of your con¬ 
stituents? I think the most important piece of advice is to avoid the “us vs. them” men¬ 
tality that we see (or hear about) all too often. Recognize that you and your users are 
(or should be) working toward the same goals and toward the success of your enter¬ 
prise. Although the goals and needs of different groups sometimes seem to be at odds, a 
little goodwill and effort to understand will make it far easier to work together toward 
the best solutions. 

Consider the other people in your organization, and work to understand their concerns 
and needs. System administration is not done in a vacuum - a system is only as worth¬ 
while as the systems and solutions that it provides. A beautiful, carefully designed, “per¬ 
fect” computing system is useless if it is conceptually pure but unsuited to solving the 
problems at hand. 

When interacting with customers or others in your organization, be honest and open. If 
there’s a problem, admit it; and if it’s a result of something you did (or didn’t do), own 
up to it, and take responsibility. Any short-term pain will be far outweighed by the 
long-term gain as your users trust and rely on you. Say what the problem is (or was) 
and what you’ve done to keep it from happening again. Give advance warning when 
you’re about to change something, and be realistic about expected downtimes. And 
remember to follow through: do what you said you would do, when you said you would 
do it. And finally, be proactive: talk with your users, solicit their feedback and concerns, 
and act on them. Earn their trust, and you’ll be far better off in the long run. 

And if the word “lusers” is a part of your vocabulary, you might want to reconsider your 
use of it. 

If you’re a manager or leader of system administrators, can the people in your group 
rely on you? Are you supportive, understanding, fair? Do you send people home when 
they are sick, or do you tell them to “tough it out”? Are you an advocate for your co¬ 
workers? Do you defend them if they’re being attacked (deservedly or not)? Do you 


And if the word "lusers” is 
a part of your vocabulary ; 
you might want to recon¬ 
sider your use of it. 
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champion them in interactions with other groups and higher-ups? Do you fight for 
appropriate conference and training budgets and extra pay or comp time when they 
work overtime? Can the people in your group rely on you? And finally, allow me to 
offer some words from Dee Hock, founder and CEO emeritus of Visa: “If you don’t 
understand that you work for your mislabeled ‘subordinates,’ then you know nothing of 
leadership. You know only tyranny.” 

When I started in system administration years ago, I spent a lot more time concentrat¬ 
ing on my “relationship” with the machines. These days, I spend a lot less time dealing 
with machines and a lot more time dealing with the people who surround them. I’m 
starting to learn which of those relationships is the more complicated and the more 
rewarding and where the true value and the true satisfaction lies. (The machines really 
don’t care whether I’m reliable or not, so long as I keep the AC power coming and the 
backup tapes loaded.) 

Well, that’s enough of that. I suspect that I’ve been “preaching to the choir” a little bit 
here. Next time I promise something a little more concrete that you can sink your teeth 
into: backups, restores, and disaster recovery. 



<des@cs.duke.edu> 


by Daniel E. 
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( ToolMcin: Upcoming Tools; Analyzing Paths ) 

It’s a new year, a new volume of ;login:, perhaps time for new resolutions. A 
resolution I made late last year was to incorporate tools from other tool makers 
into ToolMan articles, primarily to keep the series more useful and interesting. 
Toward that goal I’ve included tools by two of my co-workers in the previous 
and current issues. I’ll be writing about tools by people from the wider commu¬ 
nity in future articles, though I’ve found that working out the details in these 
situations takes much longer. But a few things are in the works, so please stay 
tuned. 


Some topics I’m considering for future articles include: 


email folder processing 

accounts 

netgroups 

disk quotas 

disk space 

finding 

comparing 

text manipulation 

documenting 

remote execution 

Web (of course) 


RCS/SCCS wrappers 
tar wrappers 
backups 
directories/files 
processes 

searching/replacing 

sorting 

printing 

email alias parsing 
scheduling/calendar 


In other words, the possibilities are wide open. Tools relating to these topics might be 
geared toward system administrators or general users. When possible, I’ll survey several 
tools relating to a given topic. If you have any tools that fit this list or other categories 
that you would like me to include, please send a note. 
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Analyzing Paths 

This issue I’ll present a couple of tools for analyzing paths. One resolves symbolic links; 
the other shows status information for each component of a path (and follows links, 
too). Both are time savers in relevant situations. 

Resolving Symbolic Links: reslink 

As filesystems evolve and grow in complexity at your site, the tangle of symbolic links 
can become quite intractable. Sometimes you need to see where a path really goes, and 
how, in order to understand some situation or problem. Getting this information quick¬ 
ly, easily, and reliably would be nice. 

Yuji Shinozaki, a fellow sysadmin here in my department, has written a tool named 
reslink for just such situations. It’ll follow the links to a file (or some other filesystem 
object) and display various information about the links, depending on which options 
you choose. 

For instance, at our site, /usr/local/bin/ contains symbolic links to files actually 
residing in other filesystems. Sometimes these links, or various intermediate compo¬ 
nents, are themselves symbolic links and, well, you get the idea. It can become difficult 
to trace and grasp any particular one. reslink is an ideal tool for dissecting this maze 
of links. 

reslink by default will list just the final path to the object specified as an argument. 
This can be useful in command substitution situations. For example: 

% reslink /usr/local/bin/latex 

/auto/pkg/tetex-0.4/tetex/bin/virtex 
% Is -1 "reslink /usr/local/bin/latex" 

-rwxr-xr-x 1 lab lab 201548 Aug 7 1996 /auto/pkg\ 

/tetex-0.4/tetex/bin/virtex 

With the -t (trace) and -v (verbose) options, details of all the links are shown: 

% reslink -tv /usr/local/bin/latex 

/usr/local/bin/latex => /auto/pkg/tetex-0.4/tetex/bin/virtex 
/usr/local/bin/latex -> /auto/pkg/tetex-0.4/bin/latex 
/auto/pkg/tetex-0.4/bin/latex -> /usr/pkg/tetex-0.4\ 

/tetex/bin/latex 
/usr/pkg -> /auto/pkg 

/auto/pkg/tetex-0.4/tetex/bin/latex -> virtex 
Another handy option is the -w (which) option, which simulates the which command: 

% reslink -wv latex 

/usr/local/bin/latex => /auto/pkg/tetex-0.4/tetex/bin/virtex 

% Is -1 "reslink -w latex" 

-rwxr-xr-x 1 lab lab 201548 Aug 7 1996 /auto/pkg/tetex-0.4\ 

/tetex/bin/virtex 

There are a few other options (both real and planned), but I wont go into the details 
here. You can pick up a copy for yourself and play around with it. 

The O’Reilly book Programming Perl by Larry Wall and Randal Schwartz includes a Perl 
script named si that is similar to reslink, sans options, si is available from your 
favorite CPAN site (paths vary) at <ftp://.../scripts/nutshell/ch6/sl>. It is also described in 
UNIX Power Tools by Jerry Peek, Tim O’Reilly, and Mike Loukides, and is available on 
the included CD archive and at <ftp://ftp.ora.com/published/orejlly/nutshell/learning_perl 
/examples.tar.Z>. 


Tool: reslink 

Abstract: resolves symbolic links 

Platforms: most UNIX 

Language: Perl 5, plus 

standard modules: 
Getopt, Cwd 

Author: Yuji Shinozaki 

<yuji@cs.duke.edu> 


Availability: 

<http://www.cs.duke.edu/~yuji/tools/reslink> 

<ftp://ftp.cs.duke.edu/pub/yuji/tools/reslink> 
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Tool: seepath 

Abstract: displays status of all 

components of a path 

Platforms: most UNIX 


Language: Bourne shell 

Author: Daniel E. Singer 

<des@cs.duke.edu> 

Availability: 

<http://www.cs.duke.edu/~des/seepath.html> 

<ftp://ftp.cs.duke.edu/pub/des/scripts/> 


Seeing the Components of a Path: seepath 

Sometimes you might need to see a little more about what’s going on with a path, 
seepath is a tool for discovering problems with permissions and modes in a path by 
giving long-listing (is -1) style status information on each of the path’s components. 
For example, Shirley may tell you that she’s running the new sizzle program and it’s 
dying with the message sizzle: cannot open /usr/project/sizzle/fizzle/driz- 
zle. To make a long story short, you could do the following: 

% pwd 

/usr/project 

% seepath sizzle/fizzle/drizzle 

seepath: /usr/project/sizzle/fizzle/drizzle 


drwxr-xr-x 

27 

root 

root 

1024 

Sep 

29 

16:21 

/ 

drwxrwxr-x 

35 

root 

sys 

1024 

Nov 

13 

09:43 

usr/ 

dr-xr-xr-x 

2 

root 

root 

3 

Dec 

6 

15:36 

project/ 

drwxrwxr-x 

34 

ziggy 

eng 

1024 

Dec 

2 

15:53 

sizzle/ 

drwxrwx- 

6 

ziggy 

eng 

512 

Nov 

20 

17:46 

fizzle/ 

-rw-rw-r— 

1 

ziggy 

eng 

2674 

Nov 

5 

19:14 

drizzle 


% groups shirley 

user acctg mgmnt 

The problem is now apparent: Shirley cannot access the fizzle directory. 

seepath can also follow links and in fact will do just that when the -F (Follow) option 
is chosen. To use the example from the reslink discussion: 

% seepath /usr/local/bin/latex 

seepath: /usr/local/bin/latex 


drwxr-xr-x 

27 

root 

root 

1024 

Sep 

29 

16:21 

/ 

drwxrwxr-x 

35 

root 

sys 

1024 

Nov 

13 

09:43 

usr/ 

drwxrwxr-x 

16 

lab 

lab 

512 

Nov 

13 

09:43 

local/ 

drwxrwxr-x 

2 

lab 

lab 

16384 

Nov 

13 

17:30 

bin/ 

lrwxrwxrwx 

1 

root 

lab 

29 

Nov 

13 

09:41 

latex -> \ 


/auto/pkg/tetex-0.4/bin/latex* 


%seepath -F /usr/local/bin/latex 

seepath: /usr/local/bin/latex 


drwxr-xr-x 

27 

root 

root 

1024 

Sep 

29 

16:21 

/ 

drwxrwxr-x 

35 

root 

sys 

1024 

Nov 

13 

09:43 

usr/ 

drwxrwxr-x 

16 

lab 

lab 

512 

Nov 

13 

09:43 

local/ 

drwxrwxr-x 

2 

lab 

lab 

16384 

Nov 

13 

17:30 

bin/ 

lrwxrwxrwx 

1 

root 

lab 

29 

Nov 

13 

09:41 

latex -> \ 



/auto/pkg/tetex-0. 

4/bin/latex* 


drwxr-xr-x 

27 

root 

root 

1024 

Sep 

29 

16:21 

/ 

dr-xr-xr-x 

2 

root 

root 

6 

Dec 

6 

16:05 

auto/ 

drwxrwxr-x 

376 

lab 

lab 

16384 

Dec 

3 

12:06 

pkg/ 

drwxr-xr-x 

6 

lab 

lab 

8192 

May 

14 

1997 

tetex-0.4/ 

drwxr-xr-x 

2 

lab 

lab 

8192 

Nov 

14 

18:04 

bin/ 

lrwxrwxrwx 

1 

lab 

lab 

34 

May 

14 

1997 

latex -> \ 



/usr/pkg/tetex-0.4/tetex/bin/latex* 

drwxr-xr-x 

27 

root 

root 

1024 

Sep 

29 

16:21 

/ 

drwxrwxr-x 

35 

root 

sys 

1024 

Nov 

13 

09:43 

usr/ 

lrwxrwxrwx 

1 

root 

root 

9 

Aug 

6 

08:12 

pkg -> /auto/pkg/ 

drwxr-xr-x 

27 

root 

root 

1024 

Sep 

29 

16:21 

/ 

dr-xr-xr-x 

2 

root 

root 

6 

Dec 

6 

16:06 

auto/ 

drwxrwxr-x 

376 

lab 

lab 

16384 

Dec 

3 

12:06 

pkg/ 

drwxr-xr-x 

6 

lab 

lab 

8192 

May 

14 

1997 

tetex-0.4/ 

drwxr-xr-x 

5 

ab 

lab 

8192 

Jun 

18 

10:13 

tetex/ 

drwxr-xr-x 

2 

lab 

lab 

8192 

Nov 

14 

18:06 

bin/ 

lrwxrwxrwx 

1 

lab 

lab 

6 

May 

14 

1997 

latex -> virtex* 

-rwxr-xr-x 

1 

lab 

lab 

201548 

Aug 

7 

1996 

virtex* 
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Time for a little filesystem reorganizing, eh? With no arguments, seepath defaults to 
analyzing the path to the current directory. 

Tools You Can Use 

reslink and seepath are tools you can use to help diagnose problems with paths, in 
regards to both symbolic links and permissions/modes. Because they can also dramati¬ 
cally reduce the number of commands you need to type in certain situations, they 
might even help delay the onset of carpal tunnel syndrome! (Sorry, this does not consti¬ 
tute a warranty.) 

If you see any ways in which these tools can be improved, the authors invite your com¬ 
ments. And remember, if you have tools that are worth sharing, please be sure to con¬ 
tact ToolMan. 


Got Q tool that's useful 
unique, way cool? ToolMan will 
make you famous! Please send a 
description to <ToolMan@usenix.org>. 


SAGE Award to O'Reilly & Associates 

At LISA ’97, Tim O’Reilly accepted the inaugural SAGE Vendor 
Special Achievement Award on behalf of O’Reilly and Associates. 
This award is presented to a commercial entity that SAGE wishes to 
recognize for its contribution in the overall field of Systems 
Administration. 




The award reads: 


The Inaugural Award we give, with thanks, to 
O’Reilly and Associates 

who for many years have been publishing consistently top-quality books 
which span the realm of systems administration and have proved 
invaluable to a generation of sysadmins. 

V___ J 
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<rik@spirit.com> 


\ 

by Rik Farrow 

Rik Farrow provides UNIX and 
Internet security consulting 
and training. He is the 
author of UNIX System 
Security and System 
Administrator's Guide to 
System V. 
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Ye gods! Not long ago, someone called me an “old geezer.” I’m not even 50 yet, 
although the gray in my sideburns makes me look older than I am (right?). Nor 
do I feel as old as other real UNIX old-timers, who actually worked with UNIX in 
the 1970s. Dave Korn presented two slides during the NT conference that listed 
all the operating systems he had worked with before he was exposed to NT. My 
experiences with computers have been much more modest, and even humorous 
at times. 

For example, I was in sixth grade the first time I got to touch a computer. As part of a 
science fair project, I was taken to a computer center in Rockville, Maryland, and 
allowed to marvel at the huge machines: disk drives the size of washing machines, 
whirring drums, refrigerator-sized magnetic tape drives, and a central processing unit 
with neon display lights showing the current address and data on the busses. As we were 
leaving, the operator stopped us. He had something he wanted to show us that he felt 
would really impress us. He loaded a deck of punched cards, and a tinny speaker on the 
side of the console started to play music. Pretty impressive. 

Actually, I was impressed. I imagined having my own computer someday, which would 
of course take up an entire floor. Later, I think I appreciated the filtered, dry, air condi¬ 
tioned air in the computer room as much as I appreciated the computer. The project I 
was assigned was to write a statistical program in IBM assembler. I balked. It was the 
concept of floating point routines that really had me floored. 

Bootstrap 

When I finished my freshman year of college, I got a summer intern position with 
General Electric in Bethesda, Maryland. I was the program librarian’s assistant and not 
required to do any programming. But I did get to operate the mainframe, an early, 
dual-processor GE 275. It took about as long to boot as my NT system today, but was 
much more interesting. First, you manually loaded two punched cards that were coded 
in binary (not Hollerith) and called “lace cards” because of all the holes. These cards 
contained the program that would then load the rest of a card deck (about 200 cards). 
That program would start the terminal controller, which read a paper tape and provid¬ 
ed a program that could read a magnetic tape. The magnetic tape actually contained the 
operating system, which, when loaded into core, finished by copying utilities onto the 
hard drives. This took about five minutes. 

Well, yes, NT gets the old, 66 Mhz 486, so it does take a while to load (especially when 
you include starting up the desktop). 

College programming classes in those days required the use of punched cards. Students 
were required to wait in line in basement rooms until a keypunch, an IBM innovation, 
was available. Then they could punch in the text of the programs in their assignments. 
Keypunching required precise typing; you could not backspace, but had to retype any 
card (one line of a program) with a single error in it. You submitted the completed deck 
to the priests running the mainframe, and the results, in the form of a 14-inch-wide 
printout wrapped around the card deck, would arrive several hours later. If you were 
lucky, this would include a core dump, which would provide you with clues about what 
went wrong. Then you could go through the process again. A single typo could cost you 
from three to as many as 18 hours (at semester’s end) of elapsed time. 
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Among the disadvantages of card decks was the potential for dropping them. Bent 
cards were a problem, but this was nothing compared to putting a deck of several hun¬ 
dred or more cards back into perfect order. 

Crash 

I went back to the university for a couple of courses in 1978. People were still using 
punched cards, but you then had the option of using DECwriters - 300 baud teletype¬ 
writers, very advanced. There were one or two “glass terminals,” but they were a bit 
scary, and there was no hard copy allowing you to review your command history. 

My most embarrassing moment came at the beginning of the semester. We were to 
enter an assembly program for a lab DEC PDP-11 computer from a listing, and I naive¬ 
ly had entered the octal memory locations along with the assembler code. Duh! Well, I 
can fix that, I thought, just a little quick substitution using the line editor. I hit return, 
and nothing happened. Soon other people began to get up and walk away from their 
terminals, and I began to look closer at the command I had just entered. Instead of 
deleting the first column of numbers, I had entered a recursive command that would 
“never” end. I had crashed the mainframe. 

I have often wanted a front panel for my computers. Something about being able to 
enter machine code in binary, and to watch lights flicker as a program executes, still 
grabs my fancy. Then again, my desktop machine is about a thousand times faster than 
that 1960s mainframe I remember fondly, and the lights wouldn’t even appear to flick¬ 
er. Perhaps that PDP-11 emulator that will run under UNIX could use a front panel? 

Crystal Ball Redux 

Another year has ended. I just reread the column I wrote at this time last year and can’t 
say I was displeased. As predicted, I have been forced to learn more about NT and still 
can’t say I like it. Although I am impressed by some aspects of NT, an operating system 
and applications hegemony written by a “team” of 8,000 programmers suffers, not sur¬ 
prisingly, from a lack of consistency. And can anyone be surprised to hear that the 
release of NT 5.0 has been delayed, likely to 1999? 

I mentioned that I expected microkernels to be on the ascendant. I have learned about 
how the design of Mach influenced the designers of NT, in particular, in the area of 
using subsystems to provide support for several APIs. I also feel vindicated in learning 
that Sun has purchased Chorus, the major microkernel vendor. Although the current 
code base for Sun’s Network Computer has been Solaris, I fully expect a microkernel 
design in the near future. 

Java has been plugging along, enmeshed in the politics of “standards.” Sun, for its own 
reasons, wants to maintain ownership of the Java standard - something I really don’t 
fault, because they have played pretty fairly so far. Microsoft is being sued by Sun to 
remove the Java branding from Internet Explorer; Netscape has already removed the 
branding because it fails total compatibility in four small areas in version 4.0. But I can 
sense the groundswell of support growing for Java among large commercial users who 
are attracted to its write-once-use-anywhere promise, reusable components, and fear of 
Microsoft. 


I have often wanted a front 
panel for my computers. 
Something about being 
able to enter machine 
code in binary ; and to 
watch lights flicker as a 
program executes, still 
grabs my fancy. 


Superhighway 

IPv6 is in its early implementation stage. The 6bone exists, and router vendors are 
beginning to support IPv6, although I have yet to hear of a large commercial installa¬ 
tion using it for anything other than small-scale testing. 
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I don’t need a $5,000 
multimedia-faster-than-a- 
desktop-hunk laptop with a 
battery life of 40 minutes. 
But then, I still use vi for 
"word processing. ” 


The Internet had several meltdowns this year, including Network Systems butchering 
the root nameservers and UUNET throwing monkey wrenches into its own backbone 
routing tables. Nobody even talks anymore about the growth of the Internet; it is just 
accepted as commonplace, without reliable quality of service, and not apt to be replaced 
by anything anytime soon. One bright spark on the horizon for organizations will be 
DSL, a means of using pairs of the Telcos’s copper wire loops to support digital trans¬ 
mission of up to 6 megabits per second. 

Intrusion Detection Systems (IDS) have become the rage. Although they will be great at 
augmenting firewalls and watching internal security, another trend will make them less 
useful. We are moving away from broadcast-style networks to switched networks. Using 
switching means that each host has a “private line,” instead of a shared media, for com¬ 
municating, with the switch acting as mediator and buffer. This means that the IDS 
people cannot attach to a network and listen to all the traffic, looking for intrusion sig¬ 
natures or unusual behavior. At best, they can monitor individual ports or the connec¬ 
tion between backbone routers. 

I am still waiting for the laptop of my dreams. It will have a real keyboard, decent-sized 
display, eight hours of battery life, and weigh less than two pounds. And it wont run 
Windows or Windows Lite (CE) or worry about supporting Microsoft products. I need 
to respond to email, take notes, and use the Internet while travelling. I don’t need a 
$5,000 multimedia-faster-than-a-desktop-hunk laptop with a battery life of 40 minutes. 
But then, I still use vi for “word processing.” 

Speaking of MS products, I was forced last year to use an LCD projector instead of 
overheads for a course I was teaching. The expectation is that everyone who presents 
uses a Microsoft product - the same one that began controlling itself several times dur¬ 
ing the NT conference, much to my amusement. I decided to convert my troff-format- 
ted course notes into a simple HTML document, which could then be displayed using 
Netscape. This worked well, although someone complained that he could still see the 
browsers controls (unlike MS Presents, which hides everything until you need to restart 
the presentation). I think a great slide presentation program could be based upon 
classes taken from the Hotjava browser or something like it. 


One Potato, Two Potato 

And while gazing into my crystal ball, I like to muse about the Microsoft Worm. Nope, 
probably hasn’t happened yet. But as the number of installed NT servers reaches a criti¬ 
cal mass, another Internet Worm-like incident will become likely. Just like the Irish 
potato famine was caused by reliance on just two species of potatoes, having lots of 
identical servers, internally complex beyond accurate documentation, can lead to a very 
interesting security meltdown. 

Life is interesting, I am traveling less (thank God), and I still find myself looking for¬ 
ward to new developments. I hope the new year finds you better off than last year and 
also looking forward to the future. 
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Interview with Bill Cheswick 


Rob You’ve been at the labs for many years. How did you get to your current 
position? 

Bill I was hired as a system administrator: what a great place to learn things. The 
a less-is-more” approach to programming and system design appealed to me greatly. 
Subsequently, I met Norman Wilson at a Decus conference, and we became close 
friends. He was an important link to the labs. 

By the way, I strongly recommend that engineers insist on attending a couple confer¬ 
ences a year so they can rub shoulders with leaders in their field and get a good per¬ 
spective of the issues in their area. This can be negotiated with prospective employers 
during the hiring process. 

I was a system administrator and postmaster for the Computer Science Research Group 
for several years. I relieved Dave Presotto of the postmaster job because I wanted to 
learn the ropes on email and the emerging Internet. I also took over the firewall he had 
built. This I redesigned and reimplemented several times. 

By the mid-1990s it was clear that I was more useful as a consultant and speaker than as 
a postmaster. Bob Flandrena and Paul Glick now handle this unenviable task. 

Rob And your current position is in Lucent, right? How has the split-up affected 
your job? 

Bill Yes, I stayed with Bell Labs, which is part of Lucent. I stayed in the same office 
and company after the AT&T/Lucent split. Many of my friends and colleagues went to 
AT&T Research, and I miss them. I am glad I stayed with the hard scientists, though. 

My work is about the same. Lucent has seemed to be much more eager to develop our 
projects than AT&T was. I think the folks at Basking Ridge (AT&T) may have mistrust¬ 
ed the labs a bit. (For example, I couldn’t sell anyone on a firewall product back in 
1991.) Lucent management made Murray Hill the corporate headquarters, and it is 
clear to me that they have been using the labs a lot more. For example, the patent office 
has snapped up a couple of ideas I gave them a couple years ago. 

There’s still plenty of basic or long-term research going on, and I think we have given 
up trimming the Physics staff. 

Rob How go the book sales? Are you chasing the wily hacker, new edition, any time 
soon? 

Bill We are at a slow exponential decay on book sales. Steve and I have been work¬ 
ing on the second edition, and clearly some stuff is really dated. For example, the first 
edition says that email is the primary reason many people connect to the net. 

The general stuff is still good, and we are focusing a bit more on that. Also, firewalls 
aren’t quite the same thrust now: they are a useful tool, but there’s lots of other aspects 
to Internet security. 

So the second edition is coming along, but I wouldn’t hold your breath: we both have a 
lot of other things to do. 

Rob How long does it take to assemble a book like yours? 


Bill Cheswick logged into his first com¬ 
puter in 1969 and has worked on oper¬ 
ating system security for more than 25 
years. Since joining Bell Laboratories in 
1987, he has worked on network securi¬ 
ty, PC viruses, mailers, the Plan 9 
Operating system, and kernel hacking. 
With Steven Bellovin, he co-authored 
Firewalls and Internet Security: 
Repelling the Wiley Hacker 

Rob Kolstad and Bill Cheswick conducted 
this interview over email during November 
and December of 1997. 
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Bill Cheswick 
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en the book 


is done , / may if 
work on dnsproxy and its 
relation to DNSsec. There 
are lots of things to do. A 
simpler ssh? Write the old 
blit games in Java or 
Limbo? I have far more 
ideas than I have time to 
work on them. 
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Bill Months and months. It’s like an English assignment that never goes away. The 
good news is that I am usually writing about something I understand, which wasn't 
true in English class. Sometimes I’ll come to a section and realize that I don't know 
what I am talking about. I have to take a break and spend some time coming up to 
speed. For both Steve and me, the consequences of the first edition are taking a lot of 
our time, so progress is slow. 

Arno Penzias, our Nobel prize-winning former VP, said that mundane work forces out 
creative work. I remember this and try to focus on writing, but email is seductive. I 
have to ignore the world for a while to get work done. 

Basically, I have to quit whining and get to work. 

Rob What interesting projects are you working on these days? 

Bill Not much, actually. The book is job one, officially. But I have spent time as a 
poster boy for Lucent, taking junkets here and there. I am recovering from foot surgery, 
which took a lot of time, and the physical therapy still does. 

When the book is done, I may work on dnsproxy and its relation to DNSsec. There are 
lots of things to do. A simpler ssh? Write the old blit games in Java or Limbo? I have far 
more ideas than I have time to work on them. Arno says this is a good sign. 

Rob You’ve been in and around so many neat projects. What’s the coolest technolo¬ 
gy that you've seen recently? 

Bill Hmm. Submillimeter radar mapping comes to mind. You get an instant topo 
map of an area. A satellite can take a picture of earth-deformations around an earth¬ 
quake zone, accurate to about a millimeter. 

Genome summaries. The journal Nature has published the source code for two differ¬ 
ent bacteria in the past year. We understand what only about half of the proteins do 
right now, but it is way cool to see the summaries so far: these proteins scavenge iron, 
this one pumps arsenic out of the cell, these are involved in DNA repair, etc., etc. You 
don’t have to be a molecular biologist to find these true nanomachines interesting. If 
you are tired of amateur hackers, go learn some chemistry and do some real comput¬ 
ing. 

I’ll put in a plug for Inferno here. It took me about two days to get up to speed on it. 
The cool thing about less-is-more programming is there is much less to learn. The two 
complete Inferno manuals are smaller than one Idiot's Guide to Using Windows 95. 

At the Hackers conference last month, there was a motorized hobby horse that simu¬ 
lates the motion of the Loma Prieta earthquake. I dropped a quarter in to check out the 
motion before spending another two bits to actually ride it. 

GPS still amazes me, and now it is under $100, $125 with CD-ROM map. Who’d have 
thought that the speed of light could be so manageable? 

Chips that perform bulk analysis of DNA sequences and proteins will change the world 
of diagnostics over the coming years. And yes, I really do want to know if I am prone to 
a particular disease. The human body needs a good mechanic. I regret that I will never 
know the results of my own autopsy. 
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Rob Any observations on the communication industry and where it's headed? 

Bill Other than predicting the Y2K problem in 1970,1 haven’t been very good at 
prediction. I’ll take a couple easy (and obvious?) shots: 

■ The net will keep growing, but at a moderated rate. Duh. So will most leading net¬ 
work companies, which remain a fine place to invest your savings. 

■ Internet telephony (and video) are doomed to remain small potatoes as long as the 
Internet retains its current general configuration and technology. Neither is likely to 
change quickly. The IP model was not designed to handle “isochronous” data, as the 
phone system is. An empty Ethernet or backbone can handle voice pretty well, but 
there is no financial incentive for the ISPs to deploy enough extra capacity to handle it 
well. You will still be able to call Bolivia on Sunday morning over the Internet, but I 
don’t think you will want to on Wednesday afternoon. It will sound like the mbone. 

■ I am told that Moore’s law is good until around 2010. If so, digital cameras are really 
going to be terrific in a few years. Sometimes I wonder what it would (will) be like 
when a $0.02 IC has an IQ of about 70 and a little microphone and speaker. What 
would an intelligent light bulb do? Would it carry on a discussion with the refrigerator 
when I am not home? Would we have an ANSI command set for it? 

■ Crypto will become ubiquitous and strong. Those fast Intel chips are even better for 
crypto than multimedia. 

■ The worst effects of the information age won’t be drug lords and porn kings with 
unreadable records. They will be targeted biological weapons. Imagine an airborne HIV 
with the infectivity of the flu or one that is especially lethal to [your least favorite eth¬ 
nic group]. These arms races parallel the Internet arms race (and all the other ones), 
but may turn out to be much nastier. Not a cheerful prediction, and I don’t really know 
how to prepare for this. But I think my children will see it. 
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NT scalability, II 

In the special ; login: issue on Windows NT [1], I promised to delve more into 
my concerns about the comparisons of UNIX and NT scalability that were pre¬ 
sented at the USENIX-NT Workshop last August. In this second article, I want 
to start with the data presented in Figure 1, which purported to show the supe¬ 
riority of NT over UNIX scalability on the common basis of the TPC-C bench¬ 
mark workload. 


20000 


~ 15000 

3 

Q. 

-C 

5 s ioooo 

o 

_c 

H 5000 
0 



Processors 


Before doing so, however, I have to assume that most readers are not familiar with the 
TPC approach to database benchmarking. Unfortunately, there is not enough space to 
go into great detail about this complex measurement process, so I can provide only the 
briefest of sketches. The interested reader can find specifics at <www.tpc.org>. 

TPC Road Rules 

Unlike many computer benchmarks (e.g., Dhrystone, Unpack, SPEC), TPC bench¬ 
marks do not exist as code that you purchase or download. Rather, TPC provides a 
(downloadable) benchmarking specification document. Anyone wishing to run the 
benchmark is free to implement the specification in any way he or she sees fit. You are 
not free, however, to interpret the TPC rules as you please. In order to report an official 
TPC result, you must write a corresponding full disclosure report that itemizes how 
you met each one of the clauses in the TPC specification. In addition, the benchmark 
runs that produced the result you wish to report must be witnessed and reviewed by an 
official TPC auditor at runtime. Your disclosure report is also reviewed by members of 
the TPC council. Any discrepancies that cannot be satisfactorily explained may lead to 
the result being withdrawn. In other words, TPC benchmarks are a serious and expen¬ 
sive undertaking that come with a high degree of credibility. Any attempt to cut corners 
is likely to be spotted and dealt with accordingly. 

The TPC Performance Race 

Currently, there are two TPC benchmarks: TPC-C (for benchmarking online database 
transaction processing: AKA OLTP systems) and TPC-D (for benchmarking decision 
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support systems: AKA DSS). The TPC-A and TPC-B benchmarks have been retired for 
two major reasons. First, these workloads corresponded to a relatively simple 
debit/credit banking transaction. Second, removal stops ongoing attempts to exploit 
any loopholes in those benchmark designs. Moreover, both the TPC-A and TPC-B were 
directed solely at OLTP performance. TPC-C is a more complex OLTP benchmark that 
uses a heterogeneous mix of five transactions accessing a database that models invento¬ 
ry control in a distributed warehouse. TPC-D is the first TPC benchmark to be directed 
at multi-user, large-scale, query-intensive systems. 

Rather than get bogged down in technical details, Tve chosen to highlight the difference 
between TPC-C and TPC-D using the following whimsical analogy with automobile 
sporting events. 

TPC-C Indianapolis 500 

TPC-C is the Indy 500 of database benchmarking. In the real Indy event, 35 vehicles 
race around a 2.5-mile circuit and the first car over the finish line on the 200th lap is 
declared the winner. The sporting focus is on the performance of individual vehicles as 
measured by their top speeds in miles per hour. 

In the TPC-C benchmark, the database transactions are analogous to the Indy race 
cars, but the performance focus is shifted away from the cars and onto the racetrack 
itself. For example, a wet track is slower than a dry one. The performance of the track 
could be measured by the number of cars per minute the track can support over the 
200 loops of the Indy 500 race. It is a measure of the raceway’s carrying capacity. 
Technically, this would be accomplished by counting the number of cars that cross the 
same place (e.g., the starting line) every five minutes (roughly the time it takes a car to 
make one loop of the raceway) and averaging those counts over the duration of the 
entire race. Under TPC road rules, any car taking longer than five minutes would not 
be counted as part of the track’s capacity. In the TPC version of the Indy 500, there is 
another rule that all cars must make at least one simultaneous pit stop (corresponding 
to a database checkpoint) and then continue again. 

In practice, when the checkered flag falls, all the cars take some time to maneuver into 
position and get up to top speed. In the TPC-C benchmark, this corresponds to the 
ramp-up period necessary to get the database cache warmed up and the system operat¬ 
ing in steady state. This ramp-up period is not included in the performance results. In 
the real TPC-C benchmark, transactions committed every half minute or so are count¬ 
ed and used to determine the average throughput measured as transactions per minute 
(or tpmC) over the entire benchmark run. Any transaction that does not commit with¬ 
in a two-second minimum response time is not counted. 

That Transparency Thing 

Furthermore, suppose you wanted to assess the Indy track capability on a worldwide 
basis (e.g., tracks in the US, Australia, Canada, and Britain). This would be a way to 
compare Indy racing with other kinds of races (e.g., NASCAR racing). The worldwide 
Indy performance would be given as the sum of the performance of each Indy raceway. 

If you raced only US cars on the US track, Australian cars on the Australian track, and 
so on, you would be unintentionally optimizing the measurement. The TPC-C version 
of measuring this worldwide Indy performance does not permit such an optimization. 
Instead, you must also run some US cars on the Australian raceway, some Australian 
cars on the British track, and every other permutation in between. Moreover, which 
car runs on which track must be determined by drawing track-car pairs out of a hat. 

In other words, you are not allowed to bias the results by knowing beforehand which 
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car will race on which track. The selection process is then said to be unbiased or 
transparent 

Similarly, in the real TPC-C benchmark, you can have four servers with four separate 
database instances, but TPC-C does not permit you to confine transactions to each 
database separately and then add the separate throughputs together to give the total 
capacity. Transactions must be distributed in such a way that any transaction can access 
any of the four database tables without knowing ahead of time which database it will 
run against. This adds realism to the benchmark. But transparency can also introduce 
some performance degradation due to the longer code paths needed to distribute the 
transactions. 

Clearly, it would be much simpler to ignore this transparency requirement and just add 
up the throughputs of more and more independent servers. That is an easy (but unre¬ 
alistic) way to generate a big throughput number without any distribution overhead. 
Thafs precisely what Microsoft did; but because it violates TPC-C road rules, they 
could not report it as a bona fide TPC-C result. It would never have gotten past the 
TPC auditor. Gray claimed this was just a “technicality.” [2] Now you can decide. On 
top of this failure, they didn’t use TPC-C transactions either, contrary to the statement 
in [3]. What did they use? We’ll never know because, not running a TPC benchmark, 
they were not subject to the disclosure rule. Gray used the term “debit-credit transac¬ 
tion,” which suggests some kind of banking transaction, but we don’t know that. 

Instead of saying Microsoft did 1 billion transactions per day, I’d prefer to call it 1 bil¬ 
lion diddleysquats per day just to remind myself that the entire Microsoft claim is 
beFUDdled. 

TPC-D Monster Tractor-Pull 

In contrast to the TPC-C Indy 500 race, TPC-D is more like a monster tractor pull. In 
the TPC-D version of the tractor pull, there are 17 vehicles of different weights that the 
tractor must tow across the arena to complete the competition. For each tow, the 
elapsed time to get across the arena is measured and used to construct an overall tow¬ 
ing capacity for the tractor. There’s no constraint on how long it takes to pull all 17 
vehicles because only the elapsed time for each pull is measured. In the real TPC-D 
benchmark, the key performance metric is the time taken to execute each of the 17 
queries. Gray did not discuss TPC-D results for SQLServer because there aren’t any for 
SQLServer. You can check for yourself at <http://www.tpc.org/execsum_TPCD.html>. But there 
are many TPC-D results on UNIX. 

Sensible Scalability Comparisons 

Figure 2 shows a comparison of TPC-C results across a wide variety of results pub¬ 
lished in 1997. The most important notable difference from Figure 1 is that there are 
no curves. That is because these are all different platforms running various flavors of 
UNIX, different RDBMSs, on different hardware. Using curves (as in Figure 1) would 
erroneously suggest that certain data belong to the same family, when they do not. 
Recall what I said about the performance analyst’s cardinal rule [1]: only change one 
thing at a time! 

There are four CPU categories shown in Figure 2: uniprocessor, two-way, four-way, and 
six-way multiprocessors. In each CPU category, the UNIX results are grouped to the 
left while the NT results are grouped to the right. I’ve selected official TPC-C UNIX 
and NT results for all of 1997 to give some reasonable definition to my requirement [1] 
that the data be in some sense contemporaneous. The selected servers have between 
one and six processors to conform to the range where NT actually tries to compete 
with UNIX servers. 
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Things look a little less impressive for NT than in Gray's benchmarketing presentation 
[2]. First, note that there is considerable variance within each UNIX group. This is to 
be expected because (unlike NT) there is no single UNIX, and the data in Figure 2 
include Oracle and Sybase running on various UNIX platforms. Typically, CPUs with 
larger second-level caches produce higher 


throughput because they can accommodate 
a larger RDBMS footprint. 


Figure 2. 1997 UNIXs vs. 1997 NTs 


Second, there is far less variation within each 
NT group. This is to be expected when there 
is only one RDBMS (viz., SQLServer) tuned 
to run relatively few Intel-based architectures. 
Note also that for the six-way configurations, 
the best UNIX result (HP/Sybase) has more 
than twice the throughput performance of 
the NT system, and the next best UNIX result 
(Sun/Sybase) is more than 30% better than 
NT. This demolishes Gray’s point based on 
Figure 1 that one needs to go to a more 
expensive 12-way UNIX system just to match 
a six-way NT in throughput. How did I arrive 
at a different conclusion? I didn’t bias the 
data by handpicking aged Solaris/Sybase 
TPC-C results for making NT comparisons. 




12 4 6 

Number of server CPUs 


Table 1 summarizes the various platform combinations that have been reported. 
Sequent has announced a parallel query result on a four-node NUMA-Q 2000 cluster 
with dual-quad CPUs (32 total CPUs). This is not a TPC-D result, however. Also, 
Compaq has an official TPC-C result with Oracle on NT (third column in Figure 2). 
There are no SQLServer results on UNIX that I know of. 


Table 1: Database and platform combinations 

RDBMS \ OS NT Solaris UNIX 


SQLServer 

✓ 

X 

9 

Sybase 

✓ 

✓ 

✓ 

Others 

(a) 

✓ 

✓ 


Price-Performance Comparisons 

We can use the disclosed price of the TPC benchmark platform expressed as $/tpmC to 
make the comparisons shown in Figure 3. When it comes to price-performance, 
Microsoft does indeed have the drop on UNIX, especially at the low end. But it’s not so 
dramatic for larger CPU configurations. In case you’re wondering, the expensive outlier 
in the two-way class is a Fujitsu UNIX box. 

Open system hardware is generally cheaper than mainframes, so how can Wintel pric¬ 
ing beat UNIX so convincingly? One way of looking at this is to recognize that history 
is simply repeating itself. Over the last 20 years, UNIX workstations and multiproces¬ 
sors have eroded the profit margins that were sacred to selling mainframe big iron. This 
occurred because UNIX boxes were cheaper to build and became more ubiquitous than 
centralized mainframes. At the outset, they could not compete with mainframe perfor¬ 
mance, but gradually, that changed as UNIX systems scaled up. 
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Figure 3. Price-Performance Comparisons 


... the PC shall do unto 
UNIX servers what UNIX 
servers hath done to main¬ 
frames. 


900 



Over the last ten years, the PC has become more ubiquitous than UNIX servers. They 
represent real commodity computers. At the outset, they could not compete with UNIX 
workstation or multiprocessor performance, but gradually, that is changing as PC- 
based systems scale up. In other words, the PC shall do unto UNIX servers what UNIX 
servers hath done to mainframes. 

Next time, I’ll consider the factors that determine hardware scalability. 
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Using Java 

Although I have tried to avoid it, I find myself writing about Java Beans. The 
migration to JDK version 1.1 brought many changes and new classes, among 
them Beans. I was at first overwhelmed by the amount of change in 1.1, as 
were some people I spoke with. But when I finally looked at Beans, I discov¬ 
ered they can actually be quite simple. In fact, a Button from the AWT could 
be used as a Bean or even a completely non-graphical class, like the following. 

public class ABean implements java.io.Serializable { 
protected int aValue; 
public void setAValue(int value) { 
theValue = value; 

} 

public int getAValueO { 
return aValue; 

} 

} 

Not very exciting, but still a Bean. The Java Bean white paper describes a bean as a 
reusable software component that can be manipulated visually in a builder tool. I 
haven’t (apparently) done anything special in the ABean class. Actually I have, and it 
relies on two aspects of Java, one new to 1.1 and both common in object design. 

The first trick has to do with reflection - the ability of a programming language to 
examine itself. The java.lang.reflect package includes classes that permit Java code 
to explore the structure of a class (under limits imposed by the security manager). 
Because each class includes all the information needed to be dynamically loaded and 
used, this should not be too surprising - you can think of it as a type of object debug¬ 
ger. But instead of just debugging, the reflect package lets you list the variables, meth¬ 
ods, and constructors of a class. Reflection is also used in Java serialization, the tech¬ 
nique used to create persistent Java objects. 

The Introspector class, included with the Beans class library, uses reflection to extract 
information from a Java Beans class. You don’t have to write this class, and every tool 
vendor can use the same class to analyze a Bean. 

What the Introspector abstracts from a Bean relies on design patterns, the second 
aspect I alluded to. Methods beginning with set (and returning void) and get are 
extracted, the get/set deleted, and the remainder of the Method name represents a 
property of the Bean. In my trivial example, the only property is AValue. Properties can 
be read-only (only a get method) or even write-only. The 1.1 AWT components are all 
written using this design pattern, so the foreground and background colors and font 
are properties of these components. (Events are also extracted, but more on that later.) 

You can ignore these patterns if you wish by building a companion class that imple¬ 
ments Beanlnfo. The Beanlnfo class is separate from the Bean itself. It is used while 
manipulating the Bean but is not required in a finished application, when it would just 
be additional baggage. 

Bean Box 

A better way to get a handle on Beans is to download the BDK, the Bean Developer’s 
Kit (<java.sun.com/beans/software>). You will need a 1.1 version of the JDK (I used JDK 
1.1.4, which differs from 1.1 in that it includes various bug fixes). At this time, only the 
Hotjava browser fully supports 1.1, which means that even if you create Bean applets, 
you can view them only with Hotjava or the 1.1 appletviewer. There is also a short 
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tutorial that guides you through using the Bean Box, a simple visual developer tool. 

Part of whats neat about the Bean Box is that although it is a bare-bones tool, most of 
the functionality is included in the Beans library. Starting up the Bean Box produces 
three windows, a palette, an empty container where you can drop the Beans, and a 
property window. The container window includes a menu bar, so please don’t be sur¬ 
prised when I mention a File menu. 

You add Beans to the container by clicking on one in the palette, then picking the cen¬ 
ter of the component in the container and clicking again. This action selects the new 
Bean and converts the third window into a display of the editable properties of the 
Bean. For example, if you choose the first Bean, OrangeButton, four properties will be 
displayed: foreground color, label, background color, and font. Clicking on the color 
properties brings up a color selection window, and clicking on the font lets you pick a 
font. 

The properties windows is part of a built-in class that any Beans development tool can 
use. If you build a Bean with properties that are more complex than can be handled 
with a simple properties editor, you can build customized property editors and step 
your developers through the process of editing the properties. 

Events 

Now you have a customizable OrangeButton, but what can you do with it? Well, sup¬ 
pose you have been experimenting with the other beans and have placed a JugglerBean 
into your container. The JugglerBean begins juggling, which can be quite annoying. You 
can slow down the juggler by increasing its delay property, but you can’t stop it. But 
there is a way, which illustrates another important aspect of Java Beans. 

Select the OrangeButton, then open the Edit menu (next to File in the menubar), and 
select Events, button push, actionPerformed. You have now chosen to add a component 
as the target of this event, and a red line will follow your cursor until you click on 
another component. Pick the juggler. 

Ah. Now a new window appears (the Event Target Dialog), which permits you to select 
an event listener method on the juggler. Select stopjuggling. The window changes to a 
message that reports that a new adaptor class is being generated. Once the window dis¬ 
appears, click on the OrangeButton and the juggler will stop. 

You use events to communicate between Beans. You can have invisible Beans, like the 
TickTock, which comes with the Bean Box and fires off TimerEvents. You can create 
your own invisible Beans, which can listen for events or property changes and fire off 
events in return. 

You can customize the Bean Box by creating your own Beans, writing a manifest, col¬ 
lecting the Beans into a jar file, and loading this jar file using the File menu in the Bean 
Box’s container window. And if you really like what you have accomplished, you can 
save the container, along with its customized Beans, by serializing them (saving them as 
a file). 

This column is no more than a basic introduction to Java Beans, just to provide a few 
of the capabilities. In subsequent columns, I plan on presenting example Beans that can 
be used in the Bean Box and will actually do something (other than juggle). If you can’t 
wait, O’Reilly’s Exploring Java (Patrick Niemeyer and Joshua Peck) has a chapter on 
Beans that is sufficient to get you going, and their Developing Java Beans (Rob 
Englander) goes into 300 pages of excellent details. 
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using C++ as a better C 


In this column we’ll look at C++ replacements for mallocO and free o, the 
operators new () and delete*). 

To give an example of how these are similar and how they differ from their C counter¬ 
parts, suppose that we want to allocate a 100-long vector of integers for some purpose. 
In C, we would say: 

int* ip; 

ip = (int*)malloc(sizeof(int) * 100); 
free((void*)ip); 

With new/delete in C++, we would have: 
int* ip; 

ip = new int[100]; 
delete [] ip; 

The most obvious difference is that the C++ approach takes care of the low-level details 
necessary to determine how many bytes to allocate. With the C++ new operator, you 
simply describe the type of the desired storage, in this example int [100]. 

The C and C++ approaches have several similarities: 

■ Neither malloc () nor new initializes the space to zeros. 

■ Both malloc () and new return a pointer that is suitably aligned for a given machine 
architecture. 

■ Both free () and delete do nothing with a NULL pointer. 

malloc () returns NULL if the space cannot be obtained. Many versions of new in 
existing C++ compilers do likewise. However, the draft ANSI C++ standard says that a 
failure to obtain storage should result in an exception being thrown or should result in 
the currently installed new handler being invoked. I assume that NULL is returned. 
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New Handlers 

The idea of a new handler can be illustrated as follows: 

extern "C" int printf(const char*, 

...); extern "C" void exit(int); 
typedef void (*new_handler) (void) ; 
new_handler set_new_handler(new_handler); 
void f() 

{ 

printf("new handler invoked due to new failure\n"); 
exit(1); 

} 

int main() 

{ 

float* p; 

set_new_handler(f); 
for (;;) 

p = new float[5000]; // something that will 

// fail eventually 

return 0; 

} 
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A new handler is a way of establishing a hook from the C++ standard library to a user 
program. set_new_handler () is a library function that records a pointer to another 
function that is to be called in the event of a new failure. 
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Deleting Arrays 

Note that saying: 

delete ip; 
instead of: 
delete [] ip; 

will work with some compilers in the example above. 

This is an area of C++ that has changed several times in recent years. There are a num¬ 
ber of issues to note. The first is that new and delete in C++ have more than one 
function. The new operator allocates storage, just like malloc () in C, but it is also 
responsible for calling the constructor for any class object that is being allocated. For 
example, if we have a String class, saying: 

String* p = new String("xxx"); 

will allocate space for a String object and then call the constructor to initialize the 
String object to the value “xxx.” In a similar way, the delete operator arranges for the 
destructor to be called for an object, and then the space is deallocated in a manner sim¬ 
ilar to the C function free (). 

If we have an array of class objects, as in: 

String* p = new String[100]; 

then a constructor must be called for each array slot, because each is a class object. 
Typically, this processing is handled by a C++ internal library function that iterates 
over the array. 

In a similar way, deallocation of an array of class objects can be done by saying: 
delete [] p; 

It used to be that you had to say: 
delete [100] p; 

but this feature is obsolete. The size of the array is recovered by the library function 
that implements the delete operator for arrays. The pointer/size pair can be stored in an 
auxiliary data structure, or the size can be stored in the allocated block before the first 
actual byte of data. 

What makes this a bit tricky is that all this work of calling constructors and destructors 
doesn’t matter for fundamental data types like int: 

int* ip; 

ip = new int[100]; 
delete ip; 

This code will work in many cases because there are no destructors to call, and deleting 
a block of storage works pretty much the same whether it’s treated as an array of ints or 
a single large chunk of bytes. 

But more recently, the ANSI Standardization Committee decided to break out the new 
and delete operators for arrays as separate functions so that a program can control the 
allocation of arrays separately from other types. For example, you can say: 
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void* operator new(unsigned int) {/* ... */ return 0;} 
void* operator new[] (unsigned int) {/* ... */ return 0;} 
void f() 

{ 

int* ip; 

ip = new int; // calls operator new() 

ip = new int[100]; // calls operator new[]() 

} 


and the appropriate functions will be called in each case. This is kind of like defining 
your own versions of the malloc () and free () library functions in C. 

Defining Your Own New/Delete Functions 

It is possible to define your own new and delete functions. For example: 

void* operator new(size_t s) 

{ 


// allocate and align storage of size s 
// handle failure via new_handler or exception 
// return pointer to storage 


void operator delete(void* p) 

{ 


// handle case where p is NULL 

// handle deallocation of p block in some way 


size_t is a typedef, typically defined to mean “unsigned int. ” It’s found in a header 
file that may vary between compiler implementations. 
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The following reports are 
published in this column: 

Whqt is POSIX ad hoc Meeting 
Whither POSIX? 

A Proposal from the Open Group 

Our Standards Reports Editor, Nick Stoughton, 
welcomes dialogue between this column and 
you, the readers. Please send any comments 
you might have to: 

<nick@usenix.org> 


An Update on 
Standards Relevant to 
USENIX Members 

by Nicholas M. 
Stoughton 

USENIX Standards Liaison 



What Is POSIX? 

I think it is safe to say that POSIX is in a 
period of crisis. Falling attendance and 
little headway in ballot resolution has put 
off many of the vendors, and they no 
longer feel that this is an effort worth fol¬ 
lowing. At the October meeting in Reno, 
the Sponsor Executive Committee (SEC), 
which governs the work of the IEEE 
Portable Applications Standards 
Committee (PASC), formed two ad hoc 
committees to examine options for the 
future, one considering the question 
“What is POSIX?” and the other looking 
at possible collaboration with The Open 
Group (TOG) for future work. 
Preliminary reports from both these 
committees are published in this column. 

Whether PASC will survive is at best 
doubtful. Industry seems to be confused 
by the existence of two closely related 
organizations, PASC and TOG, and wants 
to follow only one. The dilution of the 
core standards by specialist areas does 
not help either. I have reported previous¬ 
ly on the increase in the proportion of 
defense-related personnel at POSIX 
meetings and the building of MIL-SPECs 
by another name. 

If we cannot adapt to our circumstances, 
we will surely die. 


What is POSIX? 

Lowell Johnson <Lowell.Johnson@unisys.com> 
reports on the November 18, 1997 “What is 
POSIX” ad hoc meeting in San Jose , CA. 

The ad hoc meeting began at 4:30 after 
various meetings of the IEEE Computer 
Society were finished. My notes follow 
because there was no secretary. 
Considerable discussion had occurred 
before 4:30, with various collections of 
people participating. 

The problem as I understood it was sim¬ 
ply, “What is inside the box we call 
POSIX?” Various presentations were 
made by the participants. It is very easy 
to make generalities that hide the truth. 
For example, it was claimed that the peo¬ 
ple working on standards now are not 
representative of “the community.” 

One early proposal was that all existing 
1003.x standards be frozen. New work 
could still be called POSIX, but would 
have new numbers. Checkpoint Restart 
might be numbered 1777, but it would 
still be called POSIX. The frozen set 
would become the “core POSIX.” 

This position seemed surprising to me. 
There are several standards already pub¬ 
lished (such as the Realtime extensions) 
that go beyond the original “core” stan¬ 
dards of POSIX. 1 and POSIX.2. However, 
almost everyone agreed that the existing 
published POSIX standards should be left 
alone, and new numbers should be used 
for new standards. Only one person 
spoke up and said he would “prefer” to 
roll back to the core standards, but he 
realized it was impractical to do that 
because it would be too much work. 
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There was a long discussion about how 
you could have a standalone standard 
that did something like modify read(). 
This was thought to be part of the topic 
of another ad hoc group, but it was 
agreed that the standalone standards 
could not change any code in the base 
standards. 


Finally, we debated what the results of 
this meeting really were, and after consid¬ 
erable debate, the following compromise 
emerged: I will report on what we agreed 
and what we did not agree on. At the 
January SEC meeting, a motion will be 
made to limit the core POSIX to the 
above list of standards. 


One suggestion was to leave all currently 
sponsored projects, whether complete or 
no, in the POSIX circle. However, this 
was felt to be inappropriate. 

A question was directed at checkpoint/ 
restart: how much work would it be to 
make it a standalone document? The 
chair said it would break the group, but 
one member said she did not think it 
modified any part of POSIX. 1 [Editor's 
Note: When checkpoint/restart was a part 
of POSIX.la, it touched many parts of 
core POSIX. 1, particularly fork() and 
exec () ]. Several groups need to evaluate 
how much work it would be to change to 
a standalone document. 

A list of projects to be included in this 
new core standard was agreed upon: 
These are IN These are OUT 


After a reasonable amount of debate, and 
possible amendments, a vote will be 
taken. Then I and the appropriate WG 
chairs will take the necessary action with 
the affected projects. 

All items not included on the list should 
have sponsorship withdrawn, but they 
could be resubmitted at the same meet¬ 
ing with a new number (not 1003.x). A 
final discussion reiterated the require¬ 
ment that no future standard can break 
this core POSIX. This was agreed to be an 
absolute rule, regardless of the result of 
division issue. This means, for example, 
that anyone who adds to common func¬ 
tions like read () or write () must be 
able to fully document the enhancements 
without changing anything in the core 
standards. 


1003.1 1003.2 
1003.1b 1003.2a 
1003.1c 1003.2d 
1003.1 g 
1003.11 
1003. In 


1003.1a 1003.2b 
1003.Id 1003.2c 
1003.le 
1003.1 h 
1003.1m 
1003.1q 


It was agreed unanimously that a resolu¬ 
tion must be based on a list of projects, 
not on any sort of cutoff date. It was also 
agreed that a vote will have to be taken at 
the SEC meeting. Some people need to 
do some homework to find out how 
much work it would take to change the 
proposed standalone projects to be stand¬ 
alone documents. 


Whither POSIX? 

A Proposal From the Open Group 

Dr. Petr Janecek <p.janecek@opengroup.org> f 
Director of Standards Development at The 
Open Group , presents a proposal for closer 
collaboration with The Open Group. 

This article is based on a draft proposal 
for coordination of standardization activ¬ 
ities between the IEEE Portable 
Applications Standards Committee 
(PASC) and The Open Group (TOG). 
The proposal will be discussed by the 
members of the ad hoc committee estab¬ 
lished last October by IEEE PASC 
Sponsor Executive Committee (SEC) and 
subsequently, if appropriate, by the SEC 
itself. At this stage, it is merely a proposal 
for discussion, but views are welcome! 


Objective 

This proposal aims at eliminating dupli¬ 
cation of industry standardization efforts 
in the area of open operating systems and 
eventually eliminating the need for a sin¬ 
gle supplier to provide different products 
complying with two very close but not 
(yet) identical industry standards, POSIX 
and UNIX. 

Background 

The interest in standardization of open 
operating systems has peaked and is 
rapidly tailing off, with the industry mov¬ 
ing its standardization resources into new 
areas, in particular, the Global 
Information Infrastructure. 

All standards organizations have been 
feeling a falling interest, meeting atten¬ 
dance, and membership. 

The open operating system standards 
established through the activities of IEEE 
PASC, in particular the POSIX. 1 and 
POSIX.2 groups of standards, are stable, 
and there is little industry interest in any¬ 
thing more than their maintenance (i.e., 
error removal and interpretations). Some 
niche markets are still interested in pro¬ 
filing and further development of special 
features of POSIX (e.g., POSIX for 
embedded systems), but vendors serving 
the general market do not wish to have to 
implement such new features as part of 
their basic operating systems offering. 
POSIX has become mature. 
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The UNIX operating system, the trade¬ 
mark to which is owned by The Open 
Group (UNIX and the “X” device are reg¬ 
istered trademarks in the US and other 
countries) has become a de facto stan¬ 
dard reflecting industry’s choices in prac¬ 
tical implementation of POSIX “core” 
standards. The UNIX definition recog¬ 
nizes the POSIX standards as over-riding 
ones but is tighter, so that a UNIX-com¬ 
pliant system automatically complies 
with the POSIX standards while the 
opposite is not true. 

The two standards, POSIX and UNIX, 
use different style and format, but are 
maintained by essentially the same limit¬ 
ed group of the best of industry experts 
and are implemented by the same ven¬ 
dors. There is little reason to have the 
same group of people participating in 
two different forums carrying out what is 
essentially the same task. 

The time has come to optimize and 
merge relevant standardization activities 
of the two bodies, IEEE PASC and TOG, 
while making sure that no constituency 
feels disenfranchised. 

Industry's financial support makes it 
possible for The Open Group to provide 
professional standardization support ser¬ 
vices, including full-time managers and 
editors, as well as Web-based and other 
publications. Such facilities off-load vol¬ 
unteers from the administrative and rou¬ 
tine work and secure a high speed of 
development. 

Industry support also makes possible 
additional services building on the results 
of the standardization effort: develop¬ 
ment of test suites and management of 
testing services, branding of compliant 
systems, and professional marketing ser¬ 
vices. It is therefore felt that TOG could 
provide a good professional home for 
future POSIX as well as UNIX standard¬ 
ization activities. 


Options 

Options for collaboration between IEEE 
PASC and TOG depend on the degree of 
overlap of the current activities, the two 
organizations’ plans for future work, and 
IEEE’s interest in new services. The Open 
Group can offer IEEE and PASC the fol¬ 
lowing: 

Maintenance services for approved 
standards (.1 and .2 families) 

Home for ongoing 1003.1/.2 projects 

Home for projects in specialized areas 

Testing services Branding services 

Publication Services 

Maintenance Services 
for Approved Standards 

The following completed standards are in 
maintenance mode (i.e., error correction 
and interpretations) and suitable to be 
handled via an email-based maintenance 
structure of expert review groups provid¬ 
ed by TOG, not requiring physical meet¬ 
ings: 

POSIX. 1 System Interface 

POSIX. lb Realtime 

POSIX. lc Threads 

POSIX. lg Protocol Independent 
Interfaces (Sockets and XTI) 

POSIX.li Fixes to .lb (Realtime) 

POSIX.2 Shell & Tools 

POSIX.2a User Portability Extensions 

POSIX.5 Ada binding to POSIX. 1 

POSIX.9 FORTRAN binding to 
POSIX.1 


The mechanism could be implemented 
by opening up the membership of TOG 
base group to interested PASC members 
as belonging to the existing category of 
“invited experts.” 

Home for Ongoing 1003.1/.2 Projects 

The following core standards are still 
under development and could be handled 
via broadened participation in the Base 
Working Group of TOG: 

POSIX.la System Interface Extensions 

POSIX.In Fixes to 1003.1/lb/.li/.lc 

POSIX.2b Additional Utilities 

POSIX. 18 POSIX Profile 

The same mechanism as above, namely 
opening up the membership of TOG base 
group to interested PASC members as 
belonging to the existing category of 
“invited experts,” can be applied here. 

Home for Projects in Specialized Areas 

The following are some of the 1003 stan¬ 
dards under development that cover spe¬ 
cialized areas of interest to large and 
important customers. Although TOG 
currently has no similar activities, it 
could handle them through establishing 
new TOG working groups with open par¬ 
ticipation. The funding would have to 
come from the participants paying a 
meeting attendance fee of the same kind 
they today pay to PASC. 

POSIX.Id and POSIX.lj Additional 
Realtime Extensions 

POSIX. lh Fault Tolerance 

POSIX. lm Checkpoint/Restart 

POSIX.21 Realtime Distributed 
Systems Communications (LIS) 
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Testing Services 

The Open Group has the first complete 
POSIX Conformance Test Suite family 
in the industry for the whole of 
POSIX. 1-1996 and POSIX.2-1992. 

Further, The Open Group recently intro¬ 
duced Validation Services for FIPS 151-2 
(POSIX) in response to the termination 
of NIST validation services. TOG’s ser¬ 
vice is based on NIST procedures and 
NIST’s PCTS test suite. 

Branding Services 

The Open Group’s UNIX Brand provides 
to customers a legally binding guarantee 
of a branded product’s compliance with 
the UNIX definition now as well as in the 
future. A vendor can obtain as part of the 
UNIX Brand a certificate that includes 
the FIPS certification. Branding of 
POSIX-compliant systems would be pos¬ 
sible. 


Publication Services 

The Open Group makes its specifications 
publicly and freely available on its Web 
site. In addition, CD-ROM and electronic 
and paper publications are provided. The 
Open Access mechanism currently under 
development makes access and marking- 
up of documents over the Web easy and 
suitable for review by groups of experts. 

Summary 

Several issues still need to be worked out. 
In particular, the decision-making 
process in TOG is based on organization 
representation, while that in PASC ballot¬ 
ing groups is based on individual partici¬ 
pation. One possibility to solve this might 
be that TOG would consider the current 
PASC members interested in continuing 
their activities within TOG to be a group 
with the right to institutional representa¬ 
tion (i.e., voting rights) to the Base 
Working Group. This is exactly akin to 
the existing system, ISV and customer 


councils. The members of our Customer, 
Software Vendor, and System Councils 
vote in ballot reviews through elected 
representatives who are charged with rep¬ 
resenting the respective council’s consen¬ 
sus. My idea is that the POSIX members 
would become another “council” with 
one guaranteed vote. Of course, compa¬ 
nies that are already voting members do 
not go through this process. 

The other area that requires further 
thought and resolution is intellectual 
property rights. All existing material is 
copyright of the IEEE and is not current¬ 
ly freely available. How do we deal with 
the issue of TOG modifying this materi¬ 
al? How does it get published? I believe 
these are not insurmountable hurdles. 
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Books reviewed in this column: 


Bruce Schneier & David Banisar 



New York: John Wiley, 1997. ISBN 0-471-12297-1. 
Pp. 747. 


Bassam Halabi 



Indianapolis: Cisco Press/New Riders, 1997. 
ISBN 1-56205-652-2. Pp. 477. 


Donald E. Knuth 



Vol. 2: Seminumerical Algorithms 


3rd. ed. Reading, MA: Addison Wesley, 1998. 
ISBN 0-201-89684-2. Pp. 762. 


Patrick Chan & Rosanna Lee 



2 vols., 2nd ed. Reading, MA: Addison Wesley, 1998. 
ISBN 0-201-31002-3 & 0-201-31003-1. Pp. 2016 + 
1712. 


Brian Kahin & James H. Keller, eds. 

n ir lln jaHrLA ilvn f T*- I • I—■ ■ 7- WM 

coordinating me internet 

Cambridge, MA: MIT Press, 1997. 

ISBN 0-262-61136-8. Pp. 491. 

Jeroen Vanheste _ 

Het Internet Handboek voor 

Netwerkbeheerders 

[Internet Handbook for Network 

Administrators] 

Amsterdam, NL: Addison Wesley Longman 
Nederland, 1997. ISBN 90-6789-919-4. Pp. 374. 


S.B. Peck, et al. 



Sebastopol, CA: O’Reilly & Associates, 1997. CD- 
ROM and documentation [for Windows NT 4.0 
and higher or Windows 95). ISBN 1-56592-327-8; 
UPC 9-781565-923270. 



<peter@pedant.com> 


by Peter H. Salus \ 

Peter H. Salus is a member 
of ACM, the Early English 
Text Society, the Trollope 
Society, and is a life member 
of the American Oriental 
Society. He has held no regu¬ 
lar job in the past lustrum. 

He owns neither a dog nor a 
cat. 

J 


These last few months there have been 
several new publications that I consid¬ 
ered really outstanding. It may be that 
books for the thoughtful are being pub¬ 
lished as an antidote to VMS for 
Dummies. I don’t know the reason, but 
I’m thankful for it. 

I was a speaker at a bar meeting in 
Phoenix last November. I had thought 
that the legal community would be inter¬ 
ested in porn on the Net, etc. They 
weren’t. They were interested in privacy 
and in jurisdiction. This last is a clear 
problem where we’re dealing in a many- 
to-many universe, unlike publishing, 
radio, or TV, where there is an obvious 
single source. 

Privacy 

In the many-to-many world, firewalls can 
prevent intrusion, and encryption can 
hinder perusal. But the issue of personal 
privacy is a much more difficult one. We 
all know how much information (misin¬ 
formation?) about every one of us is out 
there: banking, credit history, motor 
vehicle, birth-death-marriage-offspring- 
adoption, property, wills and deeds, etc. - 
all are among the data available. With a 
suitable computer, it’s easy to suck up 
stuff and construct a rather elaborate 
sketch of an individual. Is this new db an 
invasion of privacy or not? In Europe, it 
apparently is. 

Bruce Schneier and David Banisar have 
put together a splendid volume on the 
encryption/public key/Clipper chip 
debates. This is a very large (and heavy) 


collection of papers, statements, congres¬ 
sional bills and reports, and newspaper 
and magazine articles about “the battle 
for privacy in the age of surveillance.” 

The documents range from Harry 
Truman’s executive order of October 24, 
1952, to the present: 45 years of govern¬ 
mental intrusion, rationalized first as 
national security and more recently as a 
fight against organized crime. (Our mod¬ 
ern Elliot Nesses sit in front of keyboards 
reading messages like “The cash is in the 
hollow tree.”) 

There are flashes of humor here, too: 
Matt Blaze’s tale of taking a SecurePhone 
to Europe is advertent; the FBI’s Sensitive 
Electronic Surveillance Techniques docu¬ 
ment, four pages of backed-out lines, is 
inadvertent. 

It will take many hours to read all of 
Schneier and Banisar. Do it. This is an 
important book. My compliments to the 
compilers. 

Routing 

For a long time, I’ve felt that routing was 
the neglected child of the Internet. 
Internet Routing Architectures may not be 
the end-all of publishing, but it is a very 
fine beginning. Published by Cisco, this is 
an excellent presentation of the design 
considerations of interdomain routing. 
There is a good deal of space devoted to 
BGP4 (the Border Gateway Protocol). I 
may actually have come away with a 
good understanding. Halabi’s opus will 
be of value in teaching folks about data 
routing manipulation. 

More Programming 

The third edition of Knuth’s Art , Vol. 2, 
Seminumerical Algorithms, has plopped 
itself on my desk. Because I have written 
earlier that I’m going to wait till all three 
volumes are out before I devote space to 
them, this announcement will have to 
serve for the nonce. 
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Java 

Addison Wesley should get an award for 
binding the two volumes of The Java 
Class Libraries : over 1,700 pages each! 
Chan and Lee have served up a detailed, 
annotated, alphabetic reference with 
thousands of lines of code examples. This 
is useful, but at 1,712 pages, volume 2 is 
not “handy” - nor, at over 2,000 pages, is 
volume 1. Nonetheless, I consider these 
indispensable references. 

Internet 

If you can recall when the Net was free 
and there were only a few hundred or a 
few thousand hosts on it, Coordinating 
the Internet may upset you a great deal. 
Personally, I feel that the chaotic nature 
of the Internet and the benign anarchy 
that prevails on it are wonderful. But it 
has become clear over the past decade 
that we need coordination, if not gover¬ 
nance. The handling of domain names is 
the least of this. In September 1996, there 
was a conference at the JFK School of 
Government at Harvard. This volume 
represents rewriting the papers delivered 
there. If public policy and the economics 
of the Internet interest you, I think you 
will have to read this. The political and 
economic future of the Net will depend 
on these views. 

The Net for Managers 

Over the years, I’ve reviewed several 
books by Jeroen Vanheste, because I con¬ 
sider it important to take note of what’s 
published in languages other than 
English - or at least those I can read or 
puzzle my way through. This Internet 
Handbook for Network Administrators is a 
first-rate job. I hope that the publisher 
has it translated into English with 
alacrity. Every aspect of the Net that’s of 
interest to a manager is covered here: 
DNS, BIND, TCP/IP, Web servers, etc., 
etc. The exposition is lucid: I especially 
enjoyed the descriptions of SLIP and 
PPP. The final chapters (on firewalls and 
secure communication) are excellent. 

The bibliography is extremely brief and 


should be expanded in the translation or 
next edition. 

Software 

When I received WebSite Professional 
V2.0,1 wasn’t quite sure what to do with 
it. I run UNIX and Linux and nothing 
from Microsoft. But I know websters 
who run NT. So I asked Steven Katz for 
his thoughts and sent him the CD-ROM 
and the docs. He wrote: 

My general impression of WebSite is 
that it is for beginners or administra¬ 
tors of small to medium-sized sites. It 
has always been and is still easy to get 
started with. The documentation, sup¬ 
port, and interface are very good. The 
default and unenhanced abilities and 
configuration of WebSite are probably 
more than adequate, possibly ideal for 
most. 

I noticed that O’Reilly had dumped Cold 
Fusion and replaced it with iHTML. This 
is probably because O’Reilly Allaire isn’t 
distributing Cold Fusion 1.0 anymore 
and O’Reilly had a significant hand in 
developing iHTML. If you’ve looked at 
WebSite Pro, you may be surprised at the 
many other changes. The most visible is 
an increase in speed. The biggest draw¬ 
back is that WebSite Pro has no remote 
administration capability. But it is vastly 
superior to Microsoft’s IIS if you’re 
involved with commercial public access. 

If you are creating Web sites that are 
meant for general public use and you 
aren’t looking to put massive amounts of 
security on the system, WebSite Pro is it. 
If you are looking for control and securi¬ 
ty and a limited number of people 
accessing the site, then IIS may be the 
one to use. 

One problem is that IIS takes over com¬ 
pletely separate server application per¬ 
missions as well. When running 
O’Reilly’s WebBoard as a separate service, 
IIS decided that it’ll take over some of its 
permissions as well. It’s quite a night¬ 
mare. 


ZD Internet Magazine had an article 
comparing Web servers, and remarked: 

One thing to note when viewing our 
performance data: WebSite Pro’s per¬ 
formance suffers due to the fact that 
the product does not cache its pages. 
However, there’s a trade-off: WebSite 
Pro developers have more control over 
the site. 

Katz also noted: 

No one has really hit the nntp server 
for NT market very hard yet. As I have 
no experience with news servers, this is 
the sort of thing I’d want to buy from 
O’Reilly and hope that it had as nice an 
interface as WebSite and is as easy to 
get started with. 

I hate the notion of an alien program 
grabbing permissions; I like the notion of 
having control; I like having robust soft¬ 
ware. It’s a clear win for WebSite Pro 
V2.0. 
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book reviews 


Jerry Peek, Tim O’Reilly & Mike Loukides _ 

Unix Power Tools , Second Edition 

O’Reilly & Associates, 1997. ISBN 1-56592-260-3. 

Pp. 1120, $59.95. Includes CD-ROM. 

Reviewed by Reginald Beardsley 

<rhb@acm.org> 

The second edition of Unix Power Tools 
reminds me of a once popular witticism 
about ALGOL: the first version was a dis¬ 
tinct improvement upon its successors. 

Some of the differences between the first 
and second editions: 

■ The section on password security has 
been deleted. 

■ The section on Awk has been substan¬ 
tially abbreviated and is now part of 
the section on batch editing. No men¬ 
tion is made of the availability of “the 
one true Awk” from Brian Kernighan’s 
home page. 

■ Short scripts included in the text of the 
first edition must now be retrieved 
from the CD-ROM (e.g., logerrs, at 
the end of the section on redirecting 
I/O). 

■ A page listing the significant changes 
to Perl w/release 5.0 has been added. (I 
mention this because the publisher’s 
blurb cited the importance of Perl as 
justification for abbreviating the treat¬ 
ment of Awk.) 

■ Highlighting of key words is now done 
by printing in medium gray rather 
than blue. Key words in sidebars are 
now printed in medium gray text on a 
light gray background! 

■ bash and tcsh have subsections of 
their own. 


There are undoubtedly some other 
changes I didn’t notice. It is, after all, still 
more than 1,000 pages. However, several 
hours spent paging through both edi¬ 
tions side by side revealed little change in 
the content. In some instances, it 
appeared that sections, such as the dis¬ 
cussion of hard and soft links, had been 
substantially rewritten. Closer examina¬ 
tion showed that the changes were really 
just improved paragraph headings. 

The deletion of content and the change 
from two-color printing to one color 
suggest to me that reducing production 
costs was the real focus of the second edi¬ 
tion. Otherwise, updating the CD-ROM 
would have been sufficient. 


Unlike Chris Lewis’s Cisco TCP/IP 
Routing Professional Reference , Scott 
Ballew’s Managing IP Networks with Cu 
Routers is not really a tutorial on confie 
uring routers; this attempts to be more 
a source of experience and wisdom in 
designing networks, selecting routing 
protocols, and then maintaining the 
whole system. It succeeds admirably in 
this regard. 

The book starts with an introduction t< 
the basics of IP networking, as one woi 
expect. This is a good introduction anc 
manages to cover nicely the debate ove 
whether one should use IP addresses p 
vided by an IP registry or ISP or whetf 
one should use RFC 1918 reserved 


Normally, I give away my old copy when 
I get a new edition of a book; shelf space 
is just too dear for me to keep two copies. 
In this case, I gave away the new edition 
and kept the first. 

Scott M. Ballew _ 

Managing IP Networks with Cisco Routers 

O’Reilly & Associates, 1997. ISBN 1-565592-320. 

Pp. 334. $29.95. 

Reviewed by Nick Christenson 

<npc@jetcafe.org> 

Today one can go to any well-stocked 
technical bookstore and easily find 
dozens of books on just about every hot 
Internet topic, be it Java programming, 
WWW site construction, ATM, Linux, or 
what have you. However, practical infor¬ 
mation on Internet routing is a topic that 
has received little attention. This is espe¬ 
cially strange because personnel with 
skills in deploying and maintaining rout¬ 
ing systems are among the most sought 
after in today’s job market. Finally, a few 
books have begun to close this gap in the 
market. This book is one of these. 


addresses. For IP veterans, there’s noth 
ing new here, but that’s not who it’s fo 

The next two chapters, covering netwo 
design, provide excellent information i 
advice for those who are looking to mi 
their networks more maintainable, as 
well as for those who are designing a n 
work from scratch. It’s apparent that tl 
author has considerable experience in 
doing this, and one would be well 
advised to follow his advice. 

After this, Ballew covers recommenda¬ 
tions in selecting network equipment 
purchase, selecting appropriate routin 
protocols (focusing on interior routin; 
protocols), and then configuring the 
router. The selection advice is sound, 1 
there is nothing really exciting here. 
Nonetheless, a lot of folks who have b 
thrust into the role of vendor selectioi 
could benefit from this advice. There 
also good advice on which routing prc 
col one ought to select under various 
cumstances, and we’re shown how to 
configure whichever routing protocol 
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one selects in a Cisco router. Be warned, 
though, that there's not enough informa¬ 
tion here to get complete novices and 
their routers out of the box and into ser¬ 
vice. For the complete novice, I would 
recommend Cisco TCP/IP Routing 
Professional Reference or, of course, the 
documentation that came with the router 
itself. 

The next two chapters, covering the tech¬ 
nical and nontechnical sides of network 
management, are my favorite in the book. 
Under nontechnical issues, we hear about 
the importance of defining the bound¬ 
aries of one’s network, developing staff 
skills, and establishing a help desk. Under 
technical issues, we cover network moni¬ 
toring, troubleshooting, and change 
management. These last topics are espe¬ 
cially well thought out. The issues Ballew 
raises on network monitoring are very 
well considered, and just about everyone 
would do well to read this before pursu¬ 
ing this topic too far. There’s also espe¬ 
cially good coverage of the use of a ver¬ 
sion control system for managing 
changes to router configuration files, a 
hot button of mine. If you’re not doing 
this, you should be, and this book tells 
you how. 

The final two chapters cover connecting 
to the outside world and network securi¬ 
ty. The chapter on exterior connections is 
decent, though not quite up to the quali¬ 
ty of the rest of the book. Exterior rout¬ 
ing as a whole is still an unexplored area 
in the literature. Ballew rightly points out 
that just the topic of BGP configuration 
issues could easily fill a book by itself. 
This is true, and it’s a book that would be 
well received. The network security chap¬ 
ter does a good job defining the issues 
and a very good job of not trying to be 
the end-all authority on this. Instead, the 
basics are presented here, and the reader 


is then referred to other good sources for 
the details. Surprisingly few authors do 
this, and it’s very refreshing. 

There are four appendices covering con¬ 
figuring interfaces and obtaining RFCs 
and Internet drafts, and IP addresses. The 
last three, though certainly appropriate, 
contain pretty basic information for 
Internet veterans. The first is a pretty 
good guide to configuring network inter¬ 
faces on Cisco routers, although no sub¬ 
stitute for the documentation or a more 
thorough work. 

Every goal the author had in writing this 
book seems to be well realized. It’s obvi¬ 
ous that Ballew has a lot of experience in 
designing and maintaining networks, and 
this experience shows through. A lot of 
wisdom about all aspects of networking 
and internetworking is present in this 
book, and every network professional 
would probably benefit from reading it 
carefully. This is probably the best single 
source of networking knowledge in print. 
Managing IP Networks with Cisco Routers 
isn’t an introduction to Cisco’s IOS, so 
beginners should supplement this work, 
but as it stands, I strongly recommend it. 
Also, Ballew’s book complements Lewis’s 
book nicely. Anyone thrust into the job of 
maintaining routers would do well to 
acquire both. 

Managing IP Networks with Cisco Routers 
is a collection of excellent advice on con¬ 
figuring and managing IP networks. 
Although it is not an introduction to 
routers, it is a collection of exceptional 
advice on networking practices from 
someone who has obviously been there. I 
recommend it for every network engineer 
or anyone else interested in these issues. 


Chris Lewis 

Cisco TCP/IP Routing Professional Reference 

McGraw-Hill, 1998. ISBN 0-07-041088-7. Pp. 402. 
$50.00. 

Reviewed by Nick Christenson 

<npc@jetcafe.org> 

Despite the dominance of Cisco in the 
routing market, the incredible number of 
router devices deployed, and the scarcity 
of professionals truly skilled in configur¬ 
ing and maintaining these devices, there 
has been a scarcity of reference works on 
Cisco routers outside of Cisco’s own doc¬ 
umentation. In fact, this book is the first 
work published outside of Cisco’s docu¬ 
mentation that covers configuration of 
routers in any detail. Finally, this gap in 
the literature has been filled. 

The book jumps right in to discuss the 
basics of routers, comparisons to bridges, 
and how to get the router out of the box 
and ready for configuration. In the sec¬ 
ond chapter, we take a step back and 
review TCP/IP. This introduction is nec¬ 
essary in a book like this, which aims to 
satisfy the needs of beginners. This deliv¬ 
ery is pretty routine and unremarkable. 

With Chapter 3, we get right into config¬ 
uring the router, covering issues such as 
bootstrapping the config and loading the 
configuration from flash memory, the 
network, or typing it in by hand. Also 
discussed is the importance of setting up 
a lab or test network for learning and 
experimentation. This is an important 
issue, and its presence here is appreciated. 
Chapter 4 covers basic routing protocols, 
RIP, OSPF, IS-IS, IGRP, and EIGRP. Also 
covered is static routing, but I believe this 
technique is not pursued with the vigor it 
deserves. Static routing has some distinct 
advantages (some of which are explored 
in Managing IP Networks With Cisco 
Routers by Scott Ballew) that deserve to 
be championed. 
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Chapter 5 talks about supporting “legacy 
LANs,” which in this book means “any¬ 
thing thats not IP.” This is a really good 
and important chapter, though, because 
there are still a lot of IPX, SNA, et al. net¬ 
works out there, and it’s still somebody’s 
job to support them. 

The next chapter discusses WAN tech¬ 
nologies, focusing on slower speed net¬ 
works like Frame Relay, SMDS, and X.25. 
It would seem that the logic is that folks 
with, for example, multiple T3s or ATM 
networks would already have someone 
on staff to maintain the router who does¬ 
n’t need to read this book. I believe this is 
an unfounded assumption, especially in 
today’s Internet. One of my biggest criti¬ 
cisms of this book is that it really shies 
away from high-end concerns. HSSI, 
ATM, BGP, and security issues are entire¬ 
ly welcome in a volume like this. 

Chapter 7 is a big one that’s all over the 
map. Much of the meat of this book is 
contained here, and although it is very 
useful information, we would have been 
better served if there were more detail 
split into several chapters. Some of the 
issues covered are whether to use an RFC 
1918 address space or not, configuring a 
Cisco router as a firewall, data compres¬ 
sion, and SNMP. Clearly, each of these is 
a very deep topic. At the very least, sug¬ 
gestions on where the reader might turn 
for more detail would be appreciated. 

The final chapter is on troubleshooting. 
Again, this is a very big topic. It is impos¬ 
sible to cover everything, but Lewis does 
a good job of providing a framework for 
a general analysis of networking prob¬ 
lems. 

Overall, Cisco TCP/IP Routing 
Professiotial Reference is an excellent 
introduction to the topic of Cisco rout¬ 
ing. The topics covered are clear, and the 
basics are well covered. For someone with 
little experience who needs to maintain a 


Cisco router, this book would be 
extremely valuable, and I’m happy to rec¬ 
ommend it as such. Nonetheless, I was 
disturbed by some of the omissions. 

In general, the book seems to cover rout¬ 
ing state of the art as of five years ago, 
but there have been some very significant 
changes that, in my opinion, are 
absolutely necessary. The first is the issue 
of classless routing (CIDR). I couldn’t 
find this critical topic mentioned once in 
the entire book. 

Another shortcoming is on the topic of 
firewalls. Even though one is instructed 
on how to set up access lists, the discus¬ 
sions on methodology are neither suffi¬ 
cient nor state of the art. There is neither 
mention of IP spoofing filters nor dis¬ 
tinctions between input and output fil¬ 
ters. The readers would be better served 
by being given a more thorough descrip¬ 
tion of how to set up various kinds of fil¬ 
ters and then strongly referred to a differ¬ 
ent source for information on general 
firewall implementation philosophies, 
such as Chapman and Zwickey’s excellent 
Building Internet Firewalls. 

A curious shortcoming, given that the 
author hails from the United Kingdom, is 
the US-centric view of networking. Most 
of the concepts can be applied to El cir¬ 
cuits in the same way that one would 
apply them to T1 lines. Nonetheless, I 
would not have minded a more interna¬ 
tional viewpoint. 

There are some fairly minor editorial 
problems with the book, nothing 
extreme, but more than one would like. 
Most of the problems occur early in the 
book and have to do with missing spaces 
in examples, which can be misleading. 
The reader would be well advised to look 
out for them. 


Despite these criticisms, this is still a very 
good and useful book. Beginners needing 
a reference on Cisco routers would be 
well advised to pick it up and read it 
carefully, although they should keep in 
mind that it does not include everything 
they probably want to know. Matched 
with Ballew’s Managing IP Networks with 
Cisco Routers, which is long on good 
design principles but shy on the configu¬ 
ration details, it becomes even stronger. 

A very good basic book on configuring 
Cisco routers, this book fills an impor¬ 
tant gap in the literature. Despite some 
significant shortcomings, it is still a 
worthwhile acquisition, especially for 
novice router administrators. 
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1998 Election for Board 
of Directors 

by Ellie Young T 

Executive Director 

<ellie@usenix.org> i 


The biennial election for officers and 
directors of the Association will be held 
this Spring. 

Ballots will be sent to all paid-up mem¬ 
bers on or about February 18. Members 
will have until March 27 to return their 
ballots, in the envelopes provided, to the 
Association office. The results of the elec¬ 
tion will be announced in comp.org. usenix, 
the USENIX Web site, and in the June 
issue of ;login:. 

The Board is made up of eight directors, 
four of whom are “at large.” The others 
are the President, Vice President, 
Secretary, and Treasurer. The balloting is 
preferential; those candidates with the 
largest number of votes are elected. Ties 
in elections for Directors shall result in 
run-off elections, the results of which 
shall be determined by a majority of the 
votes cast. 

Newly elected directors will take office at 
the conclusion of the first regularly 
scheduled meeting following the election, 
or on July 1st, whichever comes earlier. 

Report of the Nominating Committee 

The USENIX Nominating Committee, 
under the By-Laws of the Association, is 
charged with ensuring that there is at 
least one candidate for each of the four 
officer posts on the Board of Directors 
and at least four candidates for the four 
At-Large seats. We are very pleased that 
such a large number of nominees stepped 
forward. Each of the following nominees 
has indicated her/his willingness to serve. 
The By-Laws further permit nominations 
by petition. Such nominations must be of 
the form described by the By-Laws. 


news 

The Committee nominates the following 
individuals: 

President: 

Andrew Hume, AT&T Research 

Vice President: 

Greg Rose, Qualcomm 

Treasurer: 

Dan Geer, CertCo 

Secretary: 

Peter Honeyman, University of Michigan 
At-Large: 

Jon “maddog” Hall, Digital Equipment 
Corp. 

Jordan Hubbard, FreeBSD 

Darrell Long, University of California, 
Santa Cruz 

Pat Parseghian, Transmeta Corporation 
Hal Pomeranz, Deer Run Associates 
Mark Teicher, WITSEC, Inc. 

Elizabeth Zwicky, Silicon Graphics 

K. Bostic, 

Chair, Nominating Committee 

Board Meeting 
Summary 

by Ellie Young \ 

Executive Director 
<ellie@usenix.org> 


Here is a summary of the actions taken at 
the regular meetings of the USENIX 
Board of Directors held on October 25 
and 26, 1997, in San Diego, CA. 

Attendance: USENIX Board: Allman, 
Geer, Grob, Honeyman, Hume, Rose, 
Seltzer, Zwicky. USENIX Staff/Guests: 
DeMartini, Klein, Young, Collinson, 
Cohen, Harrison, Miller, Shibla, 
Stoughton. 


USENIX 

Member Benefits 

As a member of the USENIX Association, you receive 
the following benefits: 

Free subscription to ;login:, 

the Association’s magazine, published six to eight 
times a year, featuring technical articles, system 
administration tips and techniques, practical 
columns on Perl, Java, and C++, book and software 
reviews, summaries of sessions at USENIX confer¬ 
ences, and reports on various standards activities. 

Access to papers 

from the USENIX Conferences starting with 1993, 
via the USENIX Online Library on the World Wide 


Web <http://www.usenix.org>. 

Discounts on registration fees 

for all USENIX Conferences, as many as eight 
every year. 

Discounts 


on the purchase of proceedings and CD-ROMS from 
USENIX conferences. 

PGP Key Signing service 

available at conferences. 

Discounts 

10% off BSDI, Inc. personal products 
<www.bsdi.com> 

Discounts 

10% off Prime Time Freeware publications and 
software <www.ptf.com> 

Discounts 

20% off Prentice-Hall books <www.bookpool.com> 
20% off O’Reilly & Associates publications 
<www.ora.com> 

10% off Morgan Kaufmann books (give code :AL0G) 
<www.mkp.com> 

Savings 

10%-20% savings on selected titles from McGraw- 
Hill <www.books.mcgraw-hill.com>, John Wiley & 
Sons <www.wiley.com/compbooks>, The Open 
Group <www.opengroup.org>, and The MIT Press 
(give code UNIX1) <mitpress.mit.edu> 

Special subscription rates 

15% off The LINUX Journal (www.ssc.com) 

$5 off The Perl Journal 

<orwant.www.media.mit.edu/the_perl Journal> 

The right to vote 

on matters affecting the Association, its bylaws, 
election of its directors and officers 

Optional membership 

in SAGE, the System Administrators Guild 

For information regarding membership or benefits, 

please contact 

<office@usenix.org> 

Phone: 510 528 8649 
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Budget 

The assumptions behind the first draft 
budget for 1998 were discussed, and the 
budget was later approved as amended. 

Conference Fees. It was decided to raise 
conference registration fees for events 
with 3-day technical sessions by $15.00 
and full day tutorial fees for all confer¬ 
ences by $10.00. 

Proposals For Funding 

Standards. Stoughton’s proposal to wrap 
up our efforts in POSIX in 1998 and to 
continue sending a representative to 
the Open Group’s System Management 
Group was accepted. Stoughton was 
asked to write a statement regarding 
USENIX’s strategy shift from POSIX to 
the Open Group. 

Student Network Administration Project. 
The proposal submitted by the Maryland 
Virtual High School to have USENIX co¬ 
fund at a 50% level ($167,000) with the 
NSF a three-year student network admin¬ 
istration project was accepted. This pro¬ 
ject is designed to develop curriculum 
and teacher training in order to support 
the technological needs of schools and 
vocational skills of students. 

USACO. The proposal to once again fund 
the USA Computing Olympiad, and also 
travel for the team to participate in the 
International Olympiad in Informatics 
was approved. The Board also made a 


USENIX BOARD OF DIRECTORS 

Communicate directly with the USENIX Board of 
Directors by writing to: <board@usenix.org>. 

President: 

Andrew Hume <andrew@usenix.org> 

Vice President: 

Dan Geer <geer@usenix.org> 

Secretary: 

Lori Grob <grob@usenix.org> 

Treasurer: 

Eric Allman <eric@usenix.org> 


motion to express their gratitude to Rob 
Kolstad for his dedication to this project 
over the years. 

John Lions Student Prize. The proposal for 
USENIX to contribute AU $10,000 to cre¬ 
ate an endowed fund for this prize with 
the AUUG was accepted. 

Affiliations. It was agreed to renew mem¬ 
bership in the Computing Research 
Association with a $10,000 contribution. 

Conferences 

NLUUG. It was agreed that Young should 
proceed with plans for USENIX to 
co-sponsor a conference with the 
Netherlands UNIX Users Group in 1998. 

USENIX Annual Conference ’98. Greg 
Rose was appointed the liaison to the 
organizing committee that is putting 
together a third “freenix” track. 

Electronic Commerce Workshop. Bennet 
Yee will serve as program chair for this 
workshop, and Dan Geer was charged 
with coordinating a track/program on 
public key infrastructure. 

Tck/Tk Conference. Don Libes and Mike 
McLennan will serve as program co¬ 
chairs for the ’98 event. 

Windows NT Workshop. Seltzer reported 
that Thorsten von Eicken and Susan 


Directors: 

Peter Honeyman <honey@usenix.org> 
Greg Rose <ggr@usenix.org> 

Margo Seltzer <margo@usenix.org> 
Elizabeth Zwicky <zwicky@usenix.org> 

Executive Director: 

Ellie Young <ellie@usenix.org> 

CONFERENCES 

Judith F. DesHarnais 
Registration/Logistics 
Telephone: 714 588 8649 
FAX: 714 588 9706 
Email: <conference@usenix.org> 


Owicki had agreed to serve as co-chairs 
or a 1998 workshop and that it would 
also include tutorials. 

System Administration of NT. It was 
decided that a conference on large instal¬ 
lation system administration of NT will 
be held. Remy Evard and Ian Reddy will 
co-chair, tutorials will be included, and it 
will once again be co-located with the 
Windows NT Workshop. 

Domain Specific Languages Conference. 
Hume reported that the program com¬ 
mittee had recommended repeating this 
in 24 months, and that Tom Ball will 
serve as program chair 

Academic Acceptance 

There was a lot of discussion concerning 
how USENIX might gain a wider audi¬ 
ence and more acceptance in academia. 
Honeyman was asked to make a proposal 
to develop and possibly publish a com¬ 
pendium of USENIX papers that have 
had a major impact on the systems com¬ 
munity. 

Revisions to the STG and Reserve Fund 
sections of the Policies Document were 
made. A record of the STGs committee’s 
deliberations, past action, and reviews 
was to be kept 

Next Meeting 

The next meeting of the Board will be 
held on March 21, 1998, in Boston, MA. 


Cynthia Deno 

Vendor Exhibitions/Publicity/Marketing 
Telephone: 408 335 9445 
FAX: 408 335 5327 
Email: <cynthia@usenix.org> 

Daniel V. Klein 
Tutorials 

Telephone: 412 421 2332 
Email: <dvk@usenix.org> 
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Letter from the 
President: 
Looking Forward 



As I write this in January, it is common¬ 
place to self-assess, to evaluate the year 
past, and to make some plans for the year 
to come. 


What were some of my highlights of 
1997? Professionally, taking an internal 
project from a blank slate and a several 
million dollar budget to a system in pro¬ 
duction in just nine months. (Designing 
and building such a large system (2.5TB 
of disk, 150TB of tape, processing 
200+GB per day) is a blast, btw.) 
Musically, this year was good. Concerts 
were fewer but better than the previous 
year: Bruce Springsteen at a small theater 
in Asbury Park, Morrissey, and Philip 
Glass’s 60th birthday concert at Lincoln 
Center. My current CD rotation is Secret 


Samadhi (Live), Akhnaten (Glass), 
Razorblade Suitcase (Bush), Songs from 
the Capeman (Simon), and Little Jagged 
Pill (Morrissette). And finally, my wife 
and I took up sailing. 

The year’s lowlights? Working too many 
18-20 hour days, which caused substan¬ 
tial neglect of home life. Working with 
too many folks for whom process is 
much more important than results. There 
are surely more lowlights, but they’re 
obscured by my fatigue headache. 

What about USENIX? We put on some 
thought-provoking and practical work¬ 
shops (I quite liked Domain-Specific 
Languages in Santa Barbara, and had 
quite an interesting time with the NT 
crowd in Seattle - which was not so 
much a clash of cultures as a cognitive 
dissonance). We felt the eighteen month 
gap between our annual technical confer¬ 
ences more keenly than I had expected - 
my thanks to Carl Staelin for filling that 
gap with the Symposium on Internet 
Technologies & Systems. We spent S800K 
on “Good Works” (detailed on page 72), 
which are mostly aimed at student-relat¬ 
ed activities. Our staff continues to be 
outstanding and enthusiastic. They pro¬ 
duce a large amount of work with a 
small, competent group - fortunately 
they are lean and keen, rather than lean 
and mean. And last but not least, the 
USENIX Board of Directors works well 
together, with effective and productive 


meetings. I especially commend the 
Scholastic Committee, chaired by Margo 
Seltzer, for its work in outlining a charter 
and overseeing all aspects of our student 
programs. 

What about the year to come? The 
biggest event on the near horizon is the 
upcoming election for the USENIX 
Board of Directors. Three members of 
the current board are not seeking re-elec¬ 
tion (Eric Allman, Lori Grob, and Margo 
Seltzer). We will miss them dearly. The 
nominating committee, chaired by Keith 
Bostic, has assembled a good slate of can¬ 
didates for the election (see p. 69), and 
they may be joined by others who are 
nominated by petition. Although it is nei¬ 
ther my place nor my intent to tell you 
how to vote, I would like to share with 
you some of the issues that I consider 
when I vote. Hopefully, they will be use¬ 
ful to you as well. 

The basic job of the Board is to lead and 
guide the organization. In order to do 
this, the Board must be responsible and 
accountable to the membership, under¬ 
stand the organization’s operations, and 
perform some tasks For me, the latter is a 
combination of having the time and 
energy to take on extra tasks and also 
being able to work effectively within a 
group. Besides possessing these qualities, 
it is also important for potential board 
members that their experience and back¬ 
ground represent the major constituen- 
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Telephone: 510 528 8649 
Email: <cohen@usenix.org> 
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Internet Security Systems, Inc. 
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Motorola Research & Development 
MTI Technology Corporation 
Nimrod AS 

Sun Microsystems, Inc. 

Tandem Computers, Inc. 

UUNET Technologies, Inc. 
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cies of our membership. Let me illustrate 
this with examples from the previous 
election on why I voted for Margo Seltzer 
and Eric Allman. To me, Margo repre¬ 
sents our academic and research con¬ 
stituencies, provides good insight and 
understanding on the academic/student 
portion of our Good Works program, has 
a track record with USENIX, and works 
very well with others. Eric Allman has 
long term experience with the academic 
and research community as well as work¬ 
ing with a start-up company, is willing 
and able to perform the significant duties 
of treasurer, and has participated effec¬ 
tively at meetings as a program chair and 
board member for many years. 

When considering this years candidates 
and how they might best represent our 
constituencies and goals as an organiza¬ 
tion, I would want at least two active aca¬ 
demics to serve on the Board, since much 
of USENIX’s focus and money is devoted 
to student programs and academic 
research plays a large role in our confer¬ 
ences. Roughly half of our membership 
are system administrators, and we have 
SAGE as a special technical group with its 
own committee to address their specific 
needs. Yet the USENIX board needs to 
have its own direct representation of that 
group as well (such as Zwicky on the cur¬ 
rent board). The free (well, almost free, 
or at least not terribly expensive) UNIX 
community, which includes *BSD*, GNU 
and Linux (in alphabetic order), is a 
growing and vibrant subgroup; I would 
want board members familiar with that 
area (especially its goals and politics). 

And finally, but certainly not leastly, we 
need to represent and understand the 
commercial side of UNIX; the companies 
who build and sell the UNIX we use, or 
sell the products that help us use those 
UNIX systems effectively, or provide the 
human resources to help build or run our 
systems and applications. 

This is not the only, nor even the domi¬ 
nant, metric for evaluating candidates. 

But it is an important one to me, and I 
hope you’ll consider it as well. 
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USA Team Scores Gold 


by Rob Kolstad 

Rob Kolstad, editor of Jogin-. and president of BSDI, is head 
coach of the USA Computing Olympiad Team. 

<kolstad@usenix.org> 


The USA Computing Olympiad team 
earned one gold, one silver, and one 
bronze medal at the recent International 
Olympiad on Informatics (IOI) held in 
Cape Town, South Africa, November 30- 
December 9, 1997. 

15-year old whiz kid Matthew Craighead, 
high-school senior from Mendota 
Heights, Minnesota, scored a gold medal 
in his second trip to the international 
championships. Dan Adkins, MIT fresh¬ 
man and three-trip veteran, earned a sil¬ 
ver. Russell Cox, Harvard freshman and 
two-trip veteran, won a bronze medal. 
Barely missing a bronze (nine points out 
of 600) was Benjamin Matthews, Dallas, 
Texas , a sophomore in his first interna¬ 
tional competition. 

Coaches Don Piele (University of 
Wisconsin/Parkside professor), Rob 
Kolstad (BSDI president), and Hal Burch 
(CMU graduate student) accompanied 
the team to South Africa. Noncom¬ 
petition events included a visit to an 
ostrich ranch, a trip to the top of beauti¬ 
ful Table Mountain, an excursion to 
World of Birds, and a drive to the stormy 
Cape of Good Hope, where two oceans 
meet. 

This year’s competition sported problems 
different from most. Instead of problems 
begging for clever, well-programmed 
searching solutions, some of this year’s 
had more of an artificial-intelligence fla¬ 
vor. Scoring was based on a rating of the 
solution based on a “very good” solution 
rather than a perfect solution. This did 
cause a bit of trouble for some of the 
contestants! 

The 1997-1998 USA Computing 
Olympiad is well underway with three 


more contests scheduled over the next 
five months. 

Join the <hs-computing@delos.com> mailing 
list for complete info or see 
<www.usaco.org>. 


There's Gold in Good 
Works: A Report on 
USENIX Support of 
Worthwhile Projects 



by Cynthia Deno 


1 


Cynthia Deno directs the 
USENIX Association’s market¬ 
ing effort. She is always 
eager to hear from members 
with suggestions for out¬ 
reach or new services for 
members. 


<cynthia@usenix.org> 
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The USA Computing Olympiad (see pre¬ 
vious story) is just one of many “good 
works” programs USENIX supports, and 
this is not the first time USENIX has 
enjoyed the pride of a job well done. 
Every year USENIX member dues, con¬ 
ference revenue, and other funds are used 
to give back to and help nurture the 
development of the advanced computing 
systems community interpreted in the 
largest sense. In 1997 alone USENIX 
spent just under a million dollars on such 
good works. You, as a USENIX member, 
can be proud to be associated with such 
fine projects and pleased that your 
Association is in the thriving financial 
position which allows this generous level 
of support. Here are some details. 

Graduate and undergraduate college edu¬ 
cation is always of the highest priority to 
the Association. USENIX and its mem¬ 
bers value students and the research in 
the computing systems arena that is gen¬ 
erated in colleges and universities. 
Recognizing the importance of this 
work, USENIX generously funds a num- 
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ber of programs for college students. As 
Margo Seltzer, USENIX scholastic com¬ 
mittee chair and professor of computer 
science at Harvard, says “We are enthusi¬ 
astically looking forward to providing 
opportunities to an ever-increasing group 
of students.” 

Student Scholarships 

First among these programs are the 
USENIX student scholarships, which typ¬ 
ically cover some or all of a student’s 
expenses including tuition, supplies, and 
stipend. The proposal by a faculty mem¬ 
ber is easy, according to Mary Baker, pro¬ 
fessor at Stanford University, whose stu¬ 
dent was a recent recipient. Here’s what 
she had to say when notified of the 
award: “One of the things I love about 
USENIX is that there’s so little paperwork 
involved. A scholarship where the student 
and advisor don’t have to dig up tran¬ 
scripts back to kindergarten and such is a 
special thing in this world.” See: 
<http://www.usenix.org/students/scholar.html> 

Conference Participation for Students 

USENIX strongly supports graduate and 
undergraduate student participation in 
our conferences. We offer students very 
low registration fees for USENIX techni¬ 
cal sessions and tutorials. The student 
stipend program provides grants for trav¬ 
el to our conferences. Student contribu¬ 
tions to conference programs are encour¬ 
aged with best student paper awards; 
51,000 cash prizes at the annual Technical 
and LISA conferences, while $500 prizes 
are awarded at the other conferences and 
symposia. See: 

<http://www.usenix.org/students/stipend.ann.html> 

<http://www.usenix.org/students/best_paper.html> 

Student Research and Software Projects 

A generous annual budget provides for 
funding of student research projects and 
student software projects (i.e., projects 
that allow students to perform the soft¬ 
ware engineering necessary to take an 
undergraduate course project software 
package to an actual, robust, and portable 
software package useful to the greater 


computing community). With funding, 
we also pre-approve student travel 
stipends so the students can attend a 
USENIX conference and present the 
results of their work. See: 
<http://www.usenix.org/students/research.html> 
<http://www.usenix.org/students/software.htm> 

Reps on Campus 

A more innovative program is the 
USENIX Reps on Campus. In exchange 
for an annual free conference registration 
and a complimentary educational mem¬ 
bership, computer science department 
faculty and staff on various campuses 
distribute Association materials to stu¬ 
dents, maintain a library of USENIX con¬ 
ference proceedings, answer questions, 
and spread the word about USENIX’s 
activities. See: 

<http://www.usenix.org/students/outreach.html> 

The College Fund Endowment 

We are particularly proud of the USENIX 
Association’s endowment in 1997 of a 
scholarship for the College Fund; the 
endowment will provide a $10,000 annu¬ 
al scholarship to encourage minority stu¬ 
dents to study computer science. The 
College Fund (formerly United Negro 
College Fund) is one of the nation’s most 
successful higher education assistance 
organizations. On the day the scholarship 
was announced USENIX president 
Andrew Hume said, “Historically and 
currently, minorities are underrepre¬ 
sented in the technical community that is 
the core of USENIX’s membership. 
USENIX is delighted to make a substan¬ 
tial contribution towards increasing 
minority participation in the field of 
computer science.” 

Training for Settlement House Youth 

USENIX’s commitment to providing 
opportunities in computing to disadvan¬ 
taged youth was demonstrated again 
in April 1997 when we granted $65,000 
to the Polytechnic University. The 
grant is to train youth in five United 
Neighborhood settlement houses in New 
York City in Internet applications and 


help them develop skills they will need in 
the future. It supports a mentor program 
of Polytechnic students who use their 
technology skills to provide valuable 
community service and support access to 
computers and technology for all resi¬ 
dents, as they help disadvantaged 
younger students. Announcing the pro¬ 
gram, Dr. Noel Kriftcher, head of 
Polytechnic University’s David Packard 
Center for Technology and Educational 
Alliances, said: “Beyond the computer 
skills that will be developed in minority 
and female youths, these young people 
will expand their employment opportu¬ 
nities, be encouraged to continue their 
studies, be exposed to Polytechnic men¬ 
tors as role models and learn about tech¬ 
nology related careers.” See: 
<http://www.poly.edu/pr/usenix.asp>. 

Women in Computing 

Another group which has been under¬ 
represented in the computing professions 
is women. In efforts to support women’s 
fuller participation, USENIX has con¬ 
tributed to funding the production of a 
video targeted at high school and college 
students. The video “Career Encounters: 
Women in Computing” will be broadcast 
nationally on cable and satellite public 
television networks. USENIX also provid¬ 
ed travel grants to enable 32 women stu¬ 
dents to attend the Grace Hopper 
Women in Computing Conference held 
September 1997 in San Jose, California. 
See: <http://www.sdsc.edu/Hopper>. 

Pre-college Programs 

As illustrated by our support of the USA 
Computing Olympiad, pre-college com¬ 
puter education is another area of natural 
interest with USENIX. We provide funds 
to support many worthwhile projects 
designed to further the national goal 
of getting meaningful access to comput¬ 
ers into schools, encourage students in 
tool-based technology and skills, and 
enhance the quality of early education in 
computing. 
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SAGE and USENIX last year funded Evi 
Nemeth and Adam Boggs of the 
University of Colorado to present a two- 
day seminar to student sysops who are 
part of the Maryland Virtual High School 
(MVHS) program. MVHS links high 
schools via the Internet to share informa¬ 
tion and computer resources. The pro¬ 
gram is funded by a $1.5 million 
National Science Foundation grant and 
brings to the classroom a team approach 
to problem solving amid a technology- 
rich environment. Student sysops inde¬ 
pendently study advanced computer sci¬ 
ence topics while keeping school comput¬ 
ers and networks running and helping 
other students, staff and faculty learn 
computer tools. See: 

<http://mvhsLmbhs.edu/mvhsproj/sage.htmlxWe 
will co-fund the Student Network 
Administration Project with the NSF in 
1998. An outgrowth of MVHS, the pro¬ 
ject aims to develop a formal curriculum 
and teacher training to support the tech¬ 
nological needs of schools and vocational 
skills of students. Making the curriculum 
available over the Web is one of the pro¬ 
ject goals and we will let you know when 
it is available. 

The CitySpace Project is an ongoing 
series of award-winning, focused pre- 
production workshops exploring Internet 
communications, three-dimensional 
modeling, as well as fundamentals of sys¬ 
tem administration and maintenance for 
students between the ages of 10-16. 
USENIX provided seed money for this 
fun, highly interactive way to foster 
sophisticated software skills among 
young people. See: <http://cityspace.org/>. 

The WebStar Award recognizes public- 
service Web sites developed by an indi¬ 
vidual or group in the K-12 age group. 
Awards are based on a combination of 
interface design, friendliness, accuracy, 
and the value of the site to the online 
community. Dave Taylor, president of 
Intuitive Systems and columnist for 
;login:, generously donates the annual 
WebStar Award prize money. Association 


staff provide the logistics in support of 
the award and USENIX funds travel for 
the lead Webmaster and a parent to 
attend the USENIX annual technical con¬ 
ference. See: 

<http://www.intuitive.com/webstar/>. 

The John Lions Student Prize is an exam¬ 
ple of both USENIX’s commitment to 
supporting college students and our on¬ 
going cooperation role with other com¬ 
puting organizations. USENIX provided 
50% of the endowment to fund this 
annual $1,000 student prize, which is 
administered by the Australian UNIX 
Users Group (AUUG). See: 
<http://www.auug.org.au/>. 

Support for Other Organizations 

Among other organizations which have 
recently received USENIX support are the 
Internet Software Consortium (ISC) and 
the Netherlands UNIX Users Group. 
USENIX will co-sponsor the System & 
Network Administration (SANE) 
Conference with NLUUG in Fall 1998. 
See: <http://www.nluug.nl/>. 

In 1997, USENIX provided bridge fund¬ 
ing for the ISC, which is maintaining and 
developing publicly available code for key 
portions of the Internet infrastructure, 
including widely used implementations 
of the Domain Name System (BIND), 
Netnews (INN), the Dynamic Host 
Configuration Protocol (DHCP), and 
Kerberos Version 5.0. See: 
<http://www.isc.org/>. 

Lastly, USENIX has recently joined 
Computing Research Association. The 
CRA mission is to represent and inform 
the computing research community and 
to support and promote its interests. 

CRA seeks to strengthen research and 
education in the computing fields, and 
improve public policy-makers’ under¬ 
standing of the importance of computing 
and computing research in our society. 
See: <http://www.cra.org>. 


PGP Update 

Please see this issue’s back cover 
for 1998 PGP keys. 
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Twenty Years Ago 
in ;login: 


by Peter H. Salus 


Peter H. Salus is the author of A Quarter Century of UNIX 
(1994) and Casting the Net (1995). He has known Lou Katz 
for over 40 years. 


<peter@pedant.com> 



The beginning of 1978 poses several 
chronological problems for the historian. 
First, the February ;login: was mailed 
before the January issue; second, when it 
appeared, the January issue was the 
December/January issue. Should I present 
these in the order labelled or in the order 
sent? I pick the latter; it reflects reality. 
(Anyway, it makes March and April clear¬ 
er; they were mailed in reverse order.) 

The February ;login: concentrated on the 
program for the forthcoming meeting 
(May 24-27) at Columbia University's 
College of Physicians and Surgeons; Lou 
Katz was the program chair. The program 
outline was printed with the note: “The 
program is very much subject to change 
depending upon the schedules 
of speakers.” These were still the days 
when, if you had something to talk 
about, you told the chair and were put on 
the program. 

P&S was where the first UNIX Users' 
Meeting had been held in May 1974, with 
about Uvo dozen attendees. The meeting 
in Urbana in 1977 brought just over 250 
devotees together. Lou and his cohorts 
had no idea as to how many might regis¬ 
ter for the 1978 meeting. And this was a 
real meeting. Sessions ran from 1p.m. to 
11p.m. on Wednesday, 9 a.m. to 11 p.m. 
on Thursday and Friday, and 10 a.m. to 
2 p.m. on Saturday. After 2 p.m., there 
were “Visits to Laboratories.” As the 
meeting was in May, I’ll leave the rest of 
this to the next article. 


The December-January 1978 issue of 
;login: followed. It began with a note 
from Mel: 


Here at long last, with many apologies, 
is the “first” issue of ;login: for 1978. 
The “March” issue will go to the printer 
within a week or so and then “May” 
will complete the catching-up on old 
correspondence. 

Tom Ferrin's famed “fix” of the PDP 1 l's 
memory management unit (letter of 
December 9, 1977) deserves mention 
here. It was an elegant hardware solution 
to a software problem. Here’s a part of 
Tom’s letter: 

The memory management unit in the 
PDP-11/45 and 11/70 computers 
offer[s] several advantages over those 
found in the other PDP-11 family com¬ 
puters. Among the more powerful fea¬ 
tures is the ability to separate programs 
into instruction segments and data seg¬ 
ments .... 

Four PDP-11 instructions facilitate 
program communication between dif¬ 
ferent addressing modes and instruc¬ 
tion/data areas in memory. These are 
“move to/from previous instruction/ 
data memory space” (mtpi, mfpi, 
mtpd, mfpd) .... 

Because of DEC’s desire to “preserve 
the integrity of proprietary programs,” 
the “mfpi” instruction does not work 
correctly when executed with a process 
status word equal to 17xxxx (i.e., both 
current and previous modes are 
USER). This fact prevents the C sub 


routine “nargs.s” from operating as 
intended.... 

There are several solutions to this defi¬ 
ciency ... 

4. Modify the hardware to work more 
“correctly”.... After several telephone 
calls to DEC representatives and a few 
hours of looking at microcode ..., we 
have arrived at a simple modification 
to ... the PDP-11/70 cpu to allow the 
“mfpi” instruction to function proper¬ 
ly. The modification takes about 15 
minutes for an experienced person to 
implement and involves cutting one 
foil etch and adding one jumper wire 
to the M8138-YA memory manage¬ 
ment board. 

The issue also contained a dues notice of 
great complexity. I’ll let Mel Ferentz’s 
words speak for themselves: 

Enclosed is an invoice for eighteen 
months for January 1978-June 1979. As 
was explained in the recently mailed 
report of the “USENIX committee,” the 
annual dues starting July 1978 is 
$50.00. We feel honor bound to charge 
$10.00 per year for the period before 
July 1, hence the invoice is for $5.00 for 
the first six months and for $25.00 for 
each of the next six month periods. By 
striking out the appropriate lines you 
may pay for 6, 12, or 18-months. If you 
can avoid processing purchase orders 
we will be most grateful. 

There were over 250 members. 
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Thanks to our 
Volunteers 

by Ellie Young \ 

Executive Director 

<ellie@usenix.org> , 


USENIX continues to be successful and 
this would not be possible without the 
volunteers who lend their expertise and 
support for our conferences, publica¬ 
tions, members services, and philan¬ 
thropic activities. While there are many 
who serve on program committees, coor¬ 
dinate the various activities at the confer¬ 
ences, work on committees, and con¬ 
tribute to this magazine, I would like to 
make special mention of the following 
individuals who made significiant contri¬ 
butions in 1997: 

The program chairs for our 1997 
conferences: 

John Kohl 1997 USENIX Technical 
Conference 

Steve Vinoski , 3rd Conference on 
Object-Oriented Technologies & 
Systems 

Brent Welch & Joe Konstaru 5th Tcl/Tk 
Workshop 

Mike Jones & Ed Lazowska , USENIX 
Windows NT Workshop 

Phil Scan & Xev Gittler , Large-Scale 
System Administration of Windows 
NT Workshop 

Chris Ramming , Conference on 
Domain-Specific Languages 

Hal Pomeranz & Celeste Stokely , LISA 
XI 

Carl Staelin , USENIX Symposium on 
Internet Technologies & Systems 

The conferences’ Invited Talk/Special 
Track Coordinators: 

Mary Baker & Berry Kercheval for the 
invited talks at the 1997 Technical 
Conference 


Jon “maddog” Hall & Michael Johnson 
for organizing the Uselinux track at the 
USENIX Technical Conference 

Doug Schmidt for serving as tutorial 
program chair for COOTS ’97 

Rik Farrow & Pat Wilson for the invited 
talks at LISA XI 

Adam Moskowitz for organizing the 
Advanced Topics workshop at LISA XI 

Rajendra K. Raj for organizing the 
Advanced Topics Workship at COOTS. 

Evi Nemeth for organizing student vol¬ 
unteers and MBone services 

On the SAGE executive committee, I 
would like to thank the following mem¬ 
bers for their extra efforts in 1997: 

Paul Evans , who helped in the develop¬ 
ment of the Sys Admin of NT work¬ 
shop 

Hal Miller & Barb Dijker for their 
efforts in pulling together By-laws and 
Procedures documents 

Helen Harrison & Kim Trudel for their 
work on the SANS ’97 conference pro¬ 
gram 

Pat Wilson for her efforts in helping 
our Webmaster to expand the site’s ser¬ 
vices. 



And also: 

Dan Geer for serving as editor for the 
System Security: A Management 
Perspective booklet. 

Keith Bostic for serving as chair of the 
USENIX Nominating Committee for 
the upcoming Board of Directors 
Election. 

Steve Johnson for serving this past year 
as an ex-officio member of the 
USENIX Board of Directors, as well as 
being the liaison to the Computing 
Research Association. 

Eric Allman for serving as the USENIX 
liaison to the SAGE Executive 
Committee 

Margo Seltzer , Brian Bershady David 
KotZy Lori Groby & Peter Honeyman for 
serving on the USENIX Scholastic 
Committee, which initiated the many 
programs that endow and support stu¬ 
dent projects. 

Greg Rose for his efforts in providing 
and maintaining the PGP Key signing 
service to our members. 

The authors and reviewers, too numerous 
to list here, who review most of the arti¬ 
cles that appear in this magazine. 

And last but not least, the members of 
the USENIX Board of Directors who 
spend many of their “free” hours provid¬ 
ing leadership and governance. USENIX 
is grateful. 
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4th Conference on Object-Oriented Technologies and Systems (COOTS) 


April 27- May 1,1998 
El Dorado Hotel 
Santa Fe, New Mexico 


Early Registration Deadline: Monday, April 6, 1998 
Hotel Discount Deadline: Thursday, March 26 1998 


Keynote: The Shape of Things to Come 

Rick Rashid, Microsoft Research 
The relentless pace of progress in hardware and software 
technology will dramatically change computing over the next 
ten years. Software technologies once considered esoteric such as 
natural language processing, Bayesian reasoning, computer 
vision, and speech will dramatically affect not only the way 
humans and computers interact but also the way humans 
interact with each other. Moreover, the fundamental 
relationships between software and hardware will significantly 
change as software objects become more dynamic and operating 
systems increase the level of abstraction provided to developers. 
This talk addresses these coming changes and discusses how 
they will effect the uses of computing and the kinds of software 
our industry will be developing in the future. 

Richard Rashid heads the Microsoft Research Division where he has 
focused on operating systems , networking, and multiprocessors, and 
is responsible for the creation of key technologies leading to the 
development of Microsoft’s interactive TV system, now in test 
deployment. 

Before joining Microsoft, Dr. Rashid was a professor of computer 
science at Carnegie Mellon University where he directed the design 
and implementation of several influential network operating 
systems, including the Mach operating system, and published dozens 
ofpapers in the areas of computer vision, operating systems, 
programming languages for distributed processing, network 
protocols, and communications security. He is credited with co¬ 
development of one of the earliest networked computer games, Alto 
Trek. 


The technical program was not available at press time. 
For more information and updates:, see 
http://www.usenix.org/events/coots98/ 


Tutorial Program 

Monday, April 27 

Morning Session: 9:00 am - 12:30 pm 

Ml am Designing Concurrent Object-Oriented Programs in 

Java Part 1 

David Holmes, Microsoft Research Institute, Macquarie 
University; 

Doug Lea, SUNY Oswego 
M2am Understanding COM and MTS 
David Chappell, Chappell & Associates 
M3am Building Distributed CORBA Applications In C++ 

Steve Vinoski, IONA Technologies, Inc. 

Afternoon Session: 1:30pm - 5:00 pm 
M4pm Concurrent Java Programming (pt 2) 

David Holmes, Microsoft Research Institute, Macquarie 
University; 

Doug Lea, SUNY Oswego 
M5pm Designing with Patterns 
John Vlissides, IBM Research 

M6pm Distributed COM and MTS: The Programming Model, 
the Protocol and the Runtime Architecture 
Don Box, DevelopMentor 

Tuesday, April 28 

Morning Session: 9:00 am - 12:30 pm 

Tlam Framework and Component Modeling for Java with 

UML 

Desmond D’Souza, Icon Computing, Inc. 

T2am Distributed Computing with Java Remote Method 
Invocation 

Jim Waldo and Ann Wollrath, Sun Microsystems, Inc. 

T3am High-Performance C++ Programming 

Scott Meyers, Software Development Consultant 

Afternoon Session: 1:30pm - 5:00 pm 
T4pm Java/RMI, DCOM, and CORBA Interworking 
Keith Moore, Hewlett-Packard Laboratories 
T5pm Three Cool Things in C++ 

Scott Meyers, Software Development Consultant 
T6pm Java Beans 

Prithvi Rao, KiwiLabs 









3rd USENIX Workshop on Electronic Commerce 

Including Invited Presentations on Public Key Infrastructure 


Announcement and Call for Participation 


August 31-September 3,1998 
Tremont Hotel 


Boston, Massachusetts 


Sponsored by USENIX, the Advanced Computing Systems Association 


Important Dates 

Extended abstracts due: March 6, 1998 
Notification to authors: April 17, 1998 
Camera-ready final papers due: July 21, 1998 

Program Committee 

Chair: Bennet S. Yee, UC San Diego 

Public Key Infrastructure Coordinator: Daniel Geer, CertCo, LLC 

Ross Anderson, Cambridge University 

Nathaniel Borenstein, First Virtual 

Marc Donner, Morgan Stanley 

Niels Ferguson, Digicash 

Mark Manasse, Digital Equipment Coip. 

Cliff Neuman, University of Southern California 
Avi Rubin, AT&T Labs 
Win Treese, OpenMarket 
DougTygar, Carnegie Mellon University 
Hal Varian, UC Berkeley 

Overview 

The Third Workshop on Electronic Commerce will provide a 
major opportunity for researchers, experimenters, and practi¬ 
tioners in this rapidly self-defining field to exchange ideas and 
present the results of their work. It will set the technical agenda 
for work in electronic commerce by enabling workers to examine 
urgent questions, share their insights and discover connections 
with other work that might otherwise go unnoticed. To facilitate 
this, the conference will not be limited to technical problems and 
solutions, but will also consider their context: the economic and 
regulatory forces that influence the engineering choices we make, 
and the social and economic impact of network based trading 
systems. 

Each of the Workshop's three days will have two sessions focused 
on Public Key Infrastructures (PKI). This series of invited speakers 
and debates will examine the role and possible mechanisms of PKI 
in the future of electronic commerce. Emphasis will be on the 
practical side—actual field cases—and learning from experience. We 
seek, as engineers, to determine which of the various competing 
PKI claims are sustainable and practical, and, as business people, to 
learn what of the available PKI technolog)' is actually correlated 
with our needs as they truly are. 

The Workshop on Electronic Commerce will begin with tuto¬ 
rials which offer in-depth instruction in essential technologies. The 


one day of tutorials will be followed by three days of refereed 
papers and panel presentations examining topics in electronic com¬ 
merce as well as the invited sessions exploring Public Key Infra¬ 
structures. A hosted reception on Wednesday evening and evening 
Birds-of-a-Feather sessions will provide opportunities for attendees 
to meet together informally. 

Tutorials Proposals Welcome 

One day of tutorials, on August 31, will start off the Workshop.. 
USENIX s well-respected tutorials are intensive and provide 
immediately-useful information delivered by skilled instructors 
who are hands-on experts in their topic areas. Topics for the Elec¬ 
tronic Commerce Workshop will include, but are not limited to, 
security and cryptography. 

If you are interested in presenting a tutorial, please contact: 

Dan Klein, Coordinator 
Email: dvk@usenix.org 
Phone: 412.421.2332 

Public Key Infrastructures Sessions 

We welcome your suggestions of participants, topics and format. 

All speakers will be invited. Please contact the PKI Sessions 
Coordinator, DanGeer, at geer@world.std.com. 

Workshop Topics 

Two and one-half days of technical sessions will follow the tuto¬ 
rials. We welcome submissions for technical and position paper 
presentations, reports of work-in-progress, technolog)' debates, 
and identification of new open problems. Birds-of-a-Feather ses¬ 
sions in the evenings and a keynote speaker will round out the 
program. 

We seek papers that address a wide range of issues and ongoing 
developments, including, but not limited to: 

Advertising Electronic wallets Proposed systems 

Anonymous transactions Email-enabled business Protocols 

Auditability Exception handling Reliability 

Business issues Identity verification Reports on existing 

Copy protection Internet direct marketing systems 

Credit/Debit/Cash models Internet/WWW integration Rights management 
Cryptographic security Key management Service guarantees 

Customer service Legal and polity issues Services vs. digital 

Digital money Micro-transactions goods 

EDI Negotiations Settlement 

Electronic libraries Privacy Smart-cards 


Questions regarding a topics relevance to the workshop may be 
addressed to the program chair via electronic mail to 
ec98chair@usenix.org. USENIX will publish Conference Proceed¬ 
ings which are provided free to technical session attendees; addi¬ 
tional copies will be available for purchase from USENIX. 

What to Submit 

Technical paper submissions and proposals for panels must be 
received by March 6, 1998. We welcome submissions of the fol¬ 
lowing type: 

1. Refereed Papers—Full papers or extended abstracts should be 
five to 20 pages, not counting references and figures. 

2 . Panel proposals—Proposals should be three to seven pages, 
together with a list of names of potential panelists. If accepted, 
the proposer must secure the participation of panelists, and pre¬ 
pare a three to seven page summary of panel issues for inclusion 
in the Proceedings. This summary can include position state¬ 
ments by panel participants. 

3. Work-In-Progress Reports—Short, pithy, and fun, WIP reports 
introduce interesting new or ongoing work and should be 1 to 3 
pages in length. If you have work you would like to share or a 
cool idea that is not quite ready to publish, a WIP is for you! We 
are particularly interested in presenting student work. 

Each submission must include a cover letter stating the paper 
tide and authors, along with the name of the person who will act as 
the contact to the program committee. Please include a surface 
mail address, daytime and evening phone number, email and fax 
numbers and, if available, a URL for each author. If all of the 
authors are students, please indicate that in the cover letter for 
award consideration (see “Awards” below). 

USENIX workshops, like most conferences and journals, require 
that papers not be submitted simultaneously to more than one con¬ 
ference or publication and that submitted papers not be previously 
or subsequently published elsewhere. Submissions accompanied by 
non-disclosure agreement forms are not acceptable and will be 
returned to the author(s) unread. All submissions are held in the 
highest confidentiality prior to publication in the Proceedings, both 
as a matter of policy and in accord with the U.S. Copyright Act 
of 1976. 

Where to Submit Proposals 

Please send submissions to the program committee via one of the 
following methods. All submissions will be acknowledged. 

■ Preferred Method: email (Postscript or PDF formats only) to: 
ec98papers@u$enix. org. 

■ Files should be encoded for transport with uuencode or MIME 
base64 encoding. 

Authors should ensure that the PostScript is generic and portable 
so that their papers will print on a broad range of postscript 
printers, and should submit in sufficient time to allow us to con¬ 
tact the author about alternative delivery mechanisms in the event 
of network or other failure. If you send PostScript, remember the 
following: 

■ Use only the most basic fonts (TimesRoman, Helvetica, 

Courier). Other fonts are not available with every printer or 
previewer. 


■ PostScript that requires some special prolog to be loaded into the 
printer won’t work for us. Please don’t send it. 

■ If you use a PC- or Macintosh-based word processor to generate 
your PostScript, print it on a generic PostScript printer before 
sending it, to make absolutely sure that the PostScript is 
portable. 

■ If you are generating the PostScript from a program running 
under Windows, make sure that you establish the “portable” set¬ 
ting, not the “speed” setting for PostScript generation. 

A good heuristic is to make sure that recent versions of Ghost¬ 
view (e.g. Ghostview 1.5 using Ghostscript 3.33) can display 
your paper. 

■ Alternate Method: 10 copies, via postal delivery to: 

EC’98 Submissions 
USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 

For detailed submission guidelines, send email to 
ec98authors@usenix.org, refer to the conference Web page at 
www.usenix.org/events/ec98/guidelines.html, or send email to the 
program chair at ec98chair@usenix.org. 

An electronic version of this Call for Papers is available at: 
www. usenix. org/events/ec98f. 

Birds-Of-A-Feather Sessions (BoFs) 

Do you have a topic that you’d like to discuss with others? Our 
Birds-of-a-Feather Sessions may be perfect for you. BoFs are very 
interactive and informal gatherings for attendees interested in a 
particular topic. Schedule your BoF in advance by telephoning 
the USENIX Conference Office at 714.588.8649 or sending 
email to: conference@usenix.org. 

Awards 

The program committee will offer awards of $500 for the best 
paper and the best student paper. 

Registration Information 

Complete technical and tutorial programs, registration fees and 
forms and hotel information will be available on the USENIX 
Web site in June, 1998. The information will also be printable 
from a PDF file located on the Web site. However, if you would 
like to receive the printed program booklet, please request it at 
any time by email to conference@usenix.org. 

About USENIX 

USENIX is the Advanced Computing Systems Association. Since 
1975 USENIX has brought together the community of engi¬ 
neers, system administrators, and technicians working on the cut¬ 
ting edge of the computing world. For more informaiton about 
USENIX: 

URL: www.usenix.org 
Email: office@usenix.org 
Fax: 510.548.5738 
Phone: 510.528.8649 




Announcement and Call for Participation 


December 6-11,1998 
Marriott Copley Place Hotel 
Boston, Massachusetts 


Important Dates 

Extended abstracts due: June 23 1998 
Invited Talk Proposals due: June 23, 1998 
Notification to authors: July 21, 1998 
Camera-ready final papers due: October 16, 1998 

Program Committee 

Chair: Xev Gittler, Lehman Brothers 

Co-Chair: Rob Kolstad, Berkeley Software Design, I tic. 

Eric Anderson, University of California, Berkeley 
Melissa D. Binde 
Phil Cox, NTS, Inc. 

Tina Darmohray, System Experts 
Rik Farrow, Independent Consultant 
Tim Hunter, KLA-Tencor 
David Kensiski, Cisco Systems, Inc. 

Kurt J. Lidl, UUNET Technologies, Inc. 

E. Scott Men ter, ESM Services Inc. 

John Orthoefer, GTE Internetworking 
John Sellens, UUNET Canada, Inc. 

Marc Staveley, Marc Staveley Consulting 
Ozan S. Yigit, Secure Computing Corp. 

Invited Talks Coordinators 

Pat Wilson, Dartmouth College 

Phil Scarr, Netscape Communications Corporation 

Overview 

“Systems Administration in the Real World” is the theme for 
LISA ’98. 

LISA, the Systems Administration Conference, is the largest and 
oldest conference exclusively for system administrators. LISA is 
unique because the entire program is put together by veteran sys¬ 
tems administrators who know first-hand the issues you face, and 
what factors are important in devising solutions. LISA offers the 
most comprehensive program for systems administrators at all 
levels of experience, supporting a variety of platforms, and man¬ 
aging sites of all sizes. 

Systems administration is a recognized and valued professional 
skill, and one critically essential in production, mission-critical 
environments. In addition to possessing sophisticated technical 
skills and needing to enhance skills to keep up with rapidly 
changes in technologies and tools, sys admins must be on top of 


social, business even legal issues that face their organizations. How 
can you keep up? 

Whether you are a novice or senior-level sysadmin, or the man¬ 
ager of sysadmins, this year's program will have plenty to offer. 
Many different types of learning options are offered—intensive 
tutorials, refereed papers, invited talks, vendor demos in the trade 
show, and after-hours Birds-of-a-Feather sessions—with lots of dis¬ 
cussion and chances to get together with your peers. LISA is a very 
informal conference, and nobody—even industry luminaries— 
stands on ceremony. It's a terrific place to hang out and learn from 
your fellow system administrators. 

Tutorial Program, December 6-8,1998 

Gain mastery of complex techniques and technologies and you'll 
get immediate payoff within your organization. You can choose 
from up to 40 full- and half-day classes over three days. Whether 
you are a novice or senior system administrator, you will be able 
to find a tutorial to meet your needs. Tutorials cover important 
topics such as: performance tuning, administering Windows NT, 
Perl, TCP/IP troubleshooting, security, networking, network ser¬ 
vices, sendmail, Samba, legal issues, and professional develop¬ 
ment. 

Technical Sessions, December 9-11,1998 

The three days of technical sessions will deliver specific, useful 
knowledge, derived from experience, and applicable to managing 
the real-life issues you face daily. 

This year the technical sessions will be marked by flexibility in 
the kind of session formats offered. In addition to the traditional 
refereed papers, Works-in-Progress (WIP) reports and invited talks 
by leaders in the field, focused panels, mini-tutorials, jump-start 
talks, technical overviews and the like will be selected to promote 
enjoyable and interactive learning environments. They will offer 
systems administrators a chance to learn of the very latest develop¬ 
ments in important technologies, hear about solutions which have 
worked for your peers, and survey what's happening in topic areas 
of particular concern. 

The refereed papers will provide the latest findings on cutting- 
edge technologies. Refereed papers may be academic in nature, 
designed to advance the field of systems administration, or they 
may report practical solutions to specific problems. 




Conference Topics 

The Program Committee invites you to contribute to the LISA 
conference. Submissions of refereed papers or other presentations 
which address the following topics are particularly timely. Presen¬ 
tations addressing other areas of general interest are equally wel¬ 
come. 

• Innovative system administration tools and techniques 

• Distributed or automated system administration 

• Integration of emerging technologies in system administration 

• Incorporation of commercial system administration technology 

• Experiences supporting large sites (1000 users or machines) 

• Experiences supporting nomadic and wireless computing 

• High availability solutions 

• Integration of heterogeneous platforms including legacy systems 

• Managing enterprise-wide email 

• Disaster recovery solutions 

• OS/platform migration strategies 

• Performance analysis and monitoring 

• Data management 

• Security 

Invited Talk Track Proposals 

If you have a topic of interest to system administrators, but it is 
not suitable as a refereed paper, please submit a proposal to the 
Invited Talk coordinators. Please email your proposal to 
itlisa@usenbc. org. 

Tutorial Program Proposals 

To provide the best possible tutorial offerings, USENIX continu¬ 
ally solicits proposals for new tutorials. If you are interested in 
presenting a tutorial at this or other USENIX conferences, please 
contact the tutorial coordinator: 

Daniel V. Klein Tel: 1-412-421-0285 

Email: dvk@usenbc.org Fax: 1-412-421-2332 

Birds-of-a-Feather Sessions 

Birds-of-a-Feather sessions (BoFs) are very informal gatherings 
organized by attendees interested in a particular topic. BoFs will 
be held Tuesday, Wednesday, and Thursday evenings. BoFs may 
be scheduled in advance by phoning the Conference Office at 
1-714-588-8649 or via email to conference@usenbc.org. BoFs may 
also be scheduled at the conference. 

Cash Prizes 

Cash prizes will be awarded at the conference for the best paper 
and the best student paper within the refereed paper track. 

How to Submit a Refereed Paper 

An extended abstract of two to five pages is required for the paper 
selection process. Full papers are not acceptable at this stage; if 
you send a full paper, you must also include an extended abstract. 

Include references to establish that you are familiar with related 
work, and, where possible, provide detailed performance data to 
establish that you have a working implementation or measurement 
tool. 


Submissions will be judged on the quality of the written submis¬ 
sion, and whether or not the work advances the state-of-the-art of 
system administration. For more detailed author instructions and a 
sample extended abstract, send email to Usa98authors@usenbc.org or 
call USENIX at 1-510-528-8649. 

Note that LISA, like most conferences and journals, requires that 
papers not be submitted simultaneously to more than one confer¬ 
ence or publication, and that submitted papers not be previously or 
subsequently published elsewhere for a certain period of time. 
Papers accompanied by non-disclosure agreement forms are not 
acceptable and will be returned unread. All submissions are held in 
the highest confidence prior to publication in the conference pro¬ 
ceedings, both as a matter of policy and as protected by the U.S. 
Copyright Act of 1976. 

At least one author of each accepted paper presents the paper at 
the conference. Authors must provide a final paper for publication 
in the conference proceedings. Final papers are limited to 20 pages, 
including diagrams, figures and appendices. Complete instructions 
will be sent to authors of accepted papers. 

To discuss potential submissions and for inquiries regarding the 
content of the conference program, contact the program chair: 

Xev Gittler 

Email: xev@lehman.com 
Tel: 1-201-524-4160 

Where to Submit 

Please submit an extended abstract for the refereed paper track by 
two of the following methods: 

Email to: Iisa98papers@usenix.org 
Fax to: 1-510-548-5738 

Mail to: 

LISA ’98 Conference 
USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA USA 94710 

Authors: Please include the following (in a separate email mes¬ 
sage, in ascii format please, if the abstract is submitted electroni¬ 
cally) providing: 

• The title and authors of the manuscript. 

• The name of one author who will serve as a contact, with 
postal and electronic mail addresses, daytime and evening tele¬ 
phone numbers, and a fax number. 

• An indication of which, if any, authors are fiill-time students. 

Products Exhibition, December 10-11,1998 

See demonstrations of innovative solutions which can put you 
ahead of your systems, network and internet management tasks. 
The exhibition lets you preview in operation products you’ve 
heard about and get the details from well-informed vendor repre¬ 
sentatives. Compare solutions quickly and save hours of research 
looking for products and services you need! 

VENDORS: You can reach 2000 highly qualified system admin¬ 
istrators eager to purchase system administration, network, 
intra/internet and other solutions. Email: cynthia@usenbc.org 
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Announcement and Call for Papers 


LUUG 


1st International SANE Conference 


November 18-20,1998 
Maastricht, The Netherlands 


Organized by the NLUUG, the UNIX User Group - The Netherlands, co-sponsored by USENIX and 
Stichting NLnet 


Overview 

Technology is advancing, the system administration profession 
is changing rapidly, and you have to master new skills to keep 
apace. At the International SANE (System Administration and 
Networking) conference you can join the community of system 
administrators while attending a program that brings you the 
latest in tools, techniques, security, and networking. You can 
learn from tutorials, refereed papers, invited talks, and Birds-of- 
a-Feather sessions. Visit the Vendor Exhibition for the hottest 
products and the latest books available. The official language at 
the conference will be English. The conference will be located at 
the Maastricht Exposition and Conference Center, MECC. 

Tutorial Program & Technical Sessions 

On Wednesday November 18, 1998, up to four in-depth 
tutorials will be presented to you by the most popular and 
widely acclaimed speakers 

Two days of technical sessions, including keynote address, 
presentations of refereed papers, and invited talks will follow the 
tutorial day. 

Conference Organizers 

Program Co-chairs: 

Edwin Kremer, Dept, of Computer Science, Utrecht University 
Jan Christiaan van Winkel, AT Computing 

Program Committee: 

Jos Alsters, C&CZ\ KU Nijmegen 
Bob Eskes, ASR, Hollandse Signaalapparaten 
Peter den Haan, C&CZ, KU Nijmegen 
Patrick Schoo, Department of Mathematics, Utrecht University 
Michael Utermohle, Dept, of Computer Science, University of 
Paderborn 

Jos Vos, X/OS Experts in Open Systems 
Elizabeth Zwicky, Silicon Graphics, Inc. 

Event Organization: 

Chel van Gennip, Hiscom 
Marielle Klatten, NLUUG 
Monique Rours, NLUUG 

Important Dates 

Extended abstracts due: April 17, 1998 

Notification to speakers: May 8, 1998 
Final papers due: September 4, 1998 


Complete program and registration information will be avail¬ 
able in June 1998. To receive information about the conference, 
please contact: sane98-info@nluug.nl 
or visit the conference Web site: 
http://www. nluug. nl/events/sane98! 

Conference Topics 

Presentations are being solicited in areas including but not lim¬ 
ited to: Security tools and techniques. Managing enterprise¬ 
wide email (what about UCE?). Experiences with free software, 
including operating systems, in a professional environment. 
Innovative system administration tools & techniques. Distrib¬ 
uted or automated system administration. Incorporation of 
commercial system administration technology. Adventures in 
nomadic and wireless computing. Intranet development, sup¬ 
port, and maintenance. Integrating new networking technolo¬ 
gies. Integration of heterogeneous platforms. Performance 
analysis, monitoring and tuning. Support strategies in use at 
your site. Effective training techniques for system administra¬ 
tion and users. 

Invited Talks 

If you have a topic of interest that is not (yet) very well suited 
for a refereed paper submission, please submit a proposal for an 
invited talk to the Program Committee at the address: 
sane98@nluug.nl 

Refereed Paper Submissions 

An extended abstract of up to four pages is required for the 
paper selection process. Abstracts accompanied by nondisclosure 
agreement forms are not acceptable and will be returned 
unread. Authors of accepted submissions must provide a final 
paper for publication in the conference proceedings. Final 
papers are held in the highest confidence prior to publication in 
the conference proceedings. Authors agree with publication of 
the final paper in the members-only area on the NLU¬ 
UG WWW site and/or the conference CD-ROM. Please submit 
extended abstracts by one of the following methods: 

E-mail to: sane98@nluug.nl 
Fax to: +31 20 6950018 
Postal mail to: 

NLUUG PO Box 22727 
1100 DE AMSTERDAM The Netherlands 



Computer Publications from John Wiley HH 


USENIX members receive 
a 15% discount 


The Internet Navigator, 2ed 
Paul Gilster 

1-05260-4 $24.95 member price: $21.20 
it of copies: _ 

Advanced Topics in UNIX 
Ronald Leach 

1-03663-3 $24.95 member price: $21.20 

# of copies: _ 

Introduction to Client Server Systems 
Paul Renaud 

1-57774-X $34.95 member price: $29.70 

# of copies: - 

Portable UNIX 
Douglas Topham 

1-57926-2 $14.95 member price: $12.71 

# of copies: - 

UNIX, Self-Teaching Guide 
George Leach 

1-57924-6 $19.95 member price: $16.95 

# of copies: _ 

Object Oriented Programming with Turbo C++ 
Keith Weiskamp 

1-52466-2 $24.95 member price: $21.20 

# of copies: _ 

Obfuscated C and Other Mysteries 
Don Libes 

1-57805-3 $39.95 member price: $33.96 

# of copies: - 


Finding It On the Internet 
Paul Gilster 

1-03857-1 $19.95 member price $16.95 
it of copies: _ 

Internationalization: Developing Software for 
Global Markets 1-07661-9 (pub. date: 1/95) 
Tuoc Luong $29.95 member price: $25.45 
H of copies: - 

Adventures in UNIX Network Applications 

Programming 

Bill Rieken 

1-52858-7 $39.95 member price: $33.96 

# of copies: _ 

UNIX Shell Programming, 3e 
Lowell Jay Arthur 

1-59941-7 $29.95 member price: $25.45 

# of copies: _ 

The UNIX Command Reference Guide 
Kaare Christian 

1-85580-4 $32.95 member price: $28.01 
it of copies: _ 

Berkeley UNIX: A Simple & Comprehensive 
Guide 

James Wilson 

1-61582-X $40.95 member price: $34.80 

# of copies: _ 


I I Payment enclosed, plus sales tax 
I I VISA □ Mastercard 
i—i American Express 

Card No._ 

Name_ 

Firm _ 

Address_ 

City/State/Zip_ 

Signature_ 

(order invalid unless signed 


: Please send all orders to: 

John Wiley & Sons, Inc* 

Ann: K area Cooper. Special Sales 
605 Third Avenue 
New York, NY 10158 
Phone: (212)850-6789 
•: Fax: •• (212)850-6142 •' 

































AN INTRODUCTION 
TO NATURAL 
COMPUTATION 

Dana H. Ballard 

“This is a wonderful book that brings together 
in one place the modern view of computation 
as found in nature. It is well written and has 
something for everyone from the undergradu¬ 
ate to the advanced researcher." 

— Terrence J. Sejnowski, Howard Hughes 
Medical Institute at The Salk Institute for 
Biological Studies 

Complex Adaptive Systems series. A Bradford Book 
304 pp. $45 

SOFTWARE AGENTS 

edited by Jeffrey M. Bradshaw 
A comprehensive survey of the state of the 
art in the design and use of intelligent 
software agents and in the creation of 
communication ability between agents. 

450 pp. $40 paper 

Now in Paperback 

ARTIFICIAL MINDS 

Stan Franklin 

"A highly imaginative and original synthesis of 
work in the sciences of the artificial and the 
natural. The book combines the best of 
cognitive science research with artificial 
intelligence theorizing, building a bridge 
between areas usually a chasm apart. 

I enjoyed it, too!" — Robert Ornstein, 
psychobiologist and author of The Roots 
of Self, The Evolution of Consciousness, 
and Multimind 

A Bradford Book • 464 pp., 95 illus. $17.50 paper 

SLAVES OF 
THE MACHINE 

The Quickening 
of Computer Technology 

Gregory J. E. Rawlins 
Rawlins argues that it is lack of basic 
knowledge that threatens to make us slaves 
to computers, and he shows how we can take 
control of them once more. Amusing, thought- 
provoking, and packed with information, it will 
put you “under the hood" of the present-day 
computer and those of the future. 

A Bradford Book • 240 pp. $25 




USENIX members receive a 15% discount 
on the following MIT Press publications: 


THE EVOLUTION 
OF C++ 

Language Design in 
the Marketplace of Ideas 

edited by Jim Waldo 

This collection of articles traces the history of 
C++ from its infancy in the Santa Fe work¬ 
shop, to its proliferation today as the most 
popular object-ortiented language for 
microcomputers. Waldo notes in his 
postscript that in the process of evolving, the 
language has lost a clearly articulted, 
generally accepted design center, with no 
common agreement about what it should or 
should not do in the future. 

279 pp. $27.50 paper 

COMPUTABILITY 
AND COMPLEXITY 

From a Programming 
Perspective 

Neil D. Jones 

“This is an introduction to the basic concepts* 
of computability, complexity, and the theory of 
programming languages. The author knows 
very well all three subjects, has made 
important contributionsto them, has original 
insights and delightful personal points of 
view, and overall has good taste. I know of 
no previous book that provides a comprehen¬ 
sive introduction to all three subjects.” 

— Christos H. Papadimitriou, University of 
California at Berkeley 

Foundations of Computing series 
464 pp., 25 illus. $45 

Original in Paperback 

GREAT IDEAS IN 
COMPUTER SCIENCE 

A Gentle Introduction 
second edition 

Alan W. Biermann 

Presents the “great ideas” of computer 
science that together comprise the heart of 
the field. This second edition has new 
chapters on simulation, operating systems, 
and networks. In addition, the author has 
upgraded many of the original chapters based 
on student and instructor comments, with a 
view toward greater simplicity and readability. 
568 pp., 264 illus. $37.50 


The MIT Press • 55 Hayward Street • Cambridge, MA 02142-1399 USA 


To order by phone, call 800-356-0343 (US & Canada) or (617) 625-8569. 

E-mail orders: mitpress-orders@mit.edu • The operator will need this code: UNIX1 


http://www-mltpress.mlt.edu 
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T he Per/ Resource Kit—UNIX Edition gives you the most comprehensive £ I (far 

collection of Perl documentation and commercially enhanced 
software tools available today. Developed in association with Larry Wall, 

the creator of Perl, it’s the definitive Perl distribution for webmasters, programmers, and system administrators. 



The Perl Resource Kit provides: 

• Over 1,800 pages of tutorial and in-depth reference documentation for 
Perl utilities and extensions, in 4 volumes. 

• A CD-ROM containing the complete Perl distribution, plus hundreds 
of freeware Perl extensions and utilities—a complete snapshot of the 
Comprehensive Perl Archive Network (CPAN)—as well as new software 
written by Larry Wall just for the Kit. 


Essential Perl Software Tools 
All on One Convenient CD-ROM 


Experienced Perl hackers know when to create 

their own, and when they can find what they need on CPAN. Now all the power 
of CPAN—and more—is at your fingertips. The Per/ Resource Kit includes: 

• A complete snapshot of CPAN, with an install program for Solaris and 
Linux that ensures that all necessary modules are installed together. 
Also includes an easy-to-use search tool and a web-aware interface that 
^ allows you to get the latest version of each module. 

W/k • A new Java/Perl interface that allows programmers to write Java classes 
with Perl implementations. This new tool was written specially for the 
Kit by Larry Wall. 

V y Experience the power of Perl modules in areas such as CGI, web spidering, 
y database interfaces, managing mail and USENET news, user interfaces, 
security, graphics, math and statistics, and much more. 


8 y Larry Wall, 

Nate Patwardhan, Ellen Siever, 

David Futato & Brian Jepson 

1st Edition November 1997 

1812 pages, ISBN 1-56592-370-7, $149.95 

Includes 4 books & CD-ROM 


For more information, go to: http://perl.oreilly.com/log 
or call 800-998-9938. 


O’REILLY' 

SOFTWARE 




101 Morris Street, Sebastopol CA 95472 • For inquiries: 800-998-9938, 707-829-0515 • Weekdays 6am-5pm PST 
FAX: 707-829-0104 • Email a request (or our catalog: catalog@online.oreilly.com • Check out our website: 
http://sottware.oreilly.com/ • O’Reilly Technical Publications website: http://www.oreilly.com/ 







Local User Groups 


UNIX and LINUX 
Groups 

The USENIX Association will support 
local user groups by doing a mailing 
to assist in the formation of a new 
group and publishing information on 
local groups in :logiri; and on its Web 
site. Full details can be found at: 
<http://www.usenix.org/membership/LUGS.html>. 

At least one member of the group 
must be a current member of the 
Association. 

Send additions and corrections to: 
<login@usenix.org> 

California 
Bay Area 

Bay Area FreeBSD User Group 

Orange County 

UNIX Users Association of Southern 
California (UUASC) 

Colorado 

_ # _ 

Boulder 

Boulder Linux Users Group 
Front Range UNIX Users Group 

Connecticut 

The Connecticut Free UNIX Group 

District of Columbia 
Washington 

Washington Area UNIX Users Group 

Florida 

Orlando 

Central Florida UNIX Users Group 

Western 

Florida West Coast UNIX Users Group 


Georgia 

Atlanta 

Atlanta UNIX Users Group 

Kansas/Missouri 
Kansas City 

Kansas City UNIX Users Group 
(KCUUG) 

Massachusetts 

Worcester 

WPI Linux Association 
Worcester Linux User's Group 

Michigan 
Detroit/Ann Arbor 

Southeastern Michigan Sun Local Users 
and Nameless UNIX Users Group 

Missouri 
St. Louis 

St. Louis UNIX Users Group 

New England 

Northern New England UNIX Users 
Group (NNEUUG) 

New Mexico 
Albuquerque 

ASIGUNIX 

New York 
New York City 

Unigroup of New York City 

Oklahoma 

Tulsa 

Tulsa UNIX Users Group, $USR 


Texas 

Austin 

Capital Area Central Texas UNIX Users 
Society (CACTUS) 

Dallas/Fort Worth 

Dallas/Fort Worth UNIX Users Group 

Houston 

Houston UNIX Users Group (HOUNIX) 

Washington 

Seattle 

Seattle UNIX Group 

Armenia 

Yerevan 

The Armenian UNIX Users Group 
(AMUUG) was founded in December 
1996. AMUUG is open to all interested 
individuals and organizations, regardless 
of affliation, without any fee. 

Canada 

Alberta 

Calgary UNIX Users Society (CUUG) 

Manitoba 

Manitoba UNIX User Group (MUUG) 

Ontario 

Toronto Group 

Ottawa Carleton UNIX Users Group 
(OCUUG) 

Ottawa Carleton Linux Users Group 
(OCLUG) 
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System 

Administration 

Groups 

SAGE supports local groups. Full list¬ 
ing of group Web sites and other 
details can be found at: 

http://www.usenix.org/sage/locals/ 

ASUQ 

Meets first Wednesday of every third month in 
Montreal, Quebec. 

AZSAGE 

Meets monthly in the Phoenix area. 

BayLISA 

Serves the San Francisco Bay Area. 

Back Bay LISA (BBLISA) 

Serves the Boston, Massachusetts 
and New England area. 

Beach LISA 

A group for system administrators in the San Diego 
area hosts monthly meetings and the occasional 
social event. 

dc.sage 

Serves the Washington D.C. Area. 

Dallas-Fort Worth SAGE (dfwsage) 

Serves the North Texas area. 

SGROUPNAME 

Serves the New Jersey area. 


New York Systems Administrators 
(NYSA) 

Serves the New York City area. 

North Carolina System 
Administrators 

Serving central North Carolina, particularly the 
Triangle Area. 

Old Bay SAGE 

A group for sysadmins in the greater Baltimore 
Maryland area. 

SAGE-AU 

The System Administrators Guild of Australia 

Seattle SAGE Group (SSG) 

Seattle, Washington area. 

Twin Cities Systems 
Administrators (TCSA) 

Serving the Twin Cities and surrounding areas of 
Minnesota. 


EnglishBayLISA 

Serves the Vancouver, British Columbia and the 
British Columbia lower mainland. 

Houston Area Sysadmins (HASH) 

Serves the greater Houston Area. Join the mailing list 
by sending a subscribe message to hash-request 
©tree.egr.uh.edu 

Los Angeles Area Group 

A group in Los Angeles is being formed. Please con¬ 
tact Josh Geller (joshua@cae.retix.com) if you are 
interested. 


February 1998 ;login: 
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<kolstad@usenix.org> 
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~\ 

by Rob Kolstad 

Rob Kolstad is president of 
BSDI and a long-time USENIX 
member, having served as 
chair of several conferences 
and workshops, director on 
the Board, and editor of 
;login : . He is also head coach 
of the USA programming 
team. 
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Reality Check 

It’s the new year. Time for resolutions, prognostications, and taking stock. I 
think it's time for a reality check. 

Most of us work in the fastest-paced industry that has ever existed. Many of us have a 
technological bent. We watch the industry, toil on our keyboards, in meetings, or just in 
our heads. 

USENIX focuses mostly on those of us who are technical rather than members of sales 
organizations, executive management, marketing, finance, or human relations (to name 
a few). This is not to say that many of us don't work within these other kinds of organi¬ 
zations, but rather to emphasize that our goals are more often the technical. 

So what reality should we check? 

This month, let's start with trade magazines and their audience. My goodness but they 
are full of great stories! The CIO at one company saved zillions in one year; changing to 
a new database will make your company successful; Windows is the answer; UNIX is 
the answer; etc., etc. 

I regret to say that I'm more confused by most of the articles than I am enlightened. I 
understand that everyone must make a living, including reporters, but sometimes the 
articles do tend too much toward product promotion and not enough toward the sort 
of balanced practical advice that I think they think they're writing about. At least that’s 
what it looks like to me. 

I am always hoping for a bit more balance in these articles, something like “Well, we 
changed over to SchlockMeister 2.0 and things got 10% better. We were hoping for 
20%.” Instead, articles shout headlines that sound like “SchlockMeister 2.0 Speeds Cure 
for Cancer.” Cute, but not very enlightening. 

We sure don't hear too many complaints about the articles in various trade magazines, 
despite the fact that they do tend to hype things a bit. Why is that? I don't know. Plenty 
of my acquaintances believe every word printed and never check up on the story- 
behind-the-story. 

Maybe this is because of the dramatic rise in “computer literacy.” Almost everyone in 
USENIX members' companies uses a personal computer. Some small fraction of these 
people has a “knack” for dealing with them and another small fraction has an extremely 
difficult time. (My frequent racketball opponent bemoans his lack of ability in things 
technical; he can, however, draw or illustrate almost anything. I can not. Period. He felt 
much better after learning this.) 

Regrettably, those who use word processors, spreadsheets, the Web, and electronic mail 
are not necessarily those who should be making decisions about scalability, electronic 
mail servers, and world wide networks, much less a “commitment to XYZ software 
company.” And too often they don't know this. This forms the heart of a big problem, if 
you ask me. 

I’m resolving this year to try to help my customers, my associates, and those people I 
meet through my business to make sure that they are dealing with reality and not 
promises, hopes, or dreams. I am going to try to help them evaluate their solutions and 
hold their solution providers accountable for those solutions. I hope and pray that my 
“reality” is one that is close to some notion of the “real reality” and that I am not just a 
polished religious zealot of some sort. 

How goes reality in your professional life? Let me know and I’ll publish a summary if 
it's interesting. 
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Check out the program for the 
USENIX Conference including FREENIX at 
http://www.usenix.org/events/no98/ 


full range of freely redistributable software—with pointers to the code 


inux, FreeBSD, OpenBSD, Samba, NetBSD, and more 


t USENIX in 1997,1 got to FREENIX 


The Freely Redistributable Software Track at the USENIX Technical Conference 
Hatmkestheinsidnof June 15-19,1998 New Orleans, Louisiana 


iux work and to talk with 

any significant players in 

e UNIX and Linux 

mmunity." 

il Hughes, Publisher, 
iuxJournal 


FREENIX is the showcase for the latest 
developments and interesting applications 
in freely redistributable software including 
Linux, FreeBSD, OpenBSD, NetBSD, 
GNU, etc. 

A special track within the USENIX Annual 
Technical Conference, FREENIX 
attendees may choose among all of the 
conference offerings and informal get- 
togethers, including 

■ FreeBSD, Linux, OpenBSD, NetBSD, 
GNU, Samba, ete. 

■ Tutorials for in-depth instruction 

■ Keynote speakers 

■ Refereed presentations 

■ Invited talks 

■ Works-in-Progress reports 

■ Birds-of-a-Feather sessions 

■ The Guru is IN” 

■ Products Exhibition 


FREENIX Committee Chair: 

Jon “inaddog” Hall, Digital Equipment 
Corporation 

For the detailed USENIX conference 
program (available March) including 
FREENIX, special events and registration 
online, go to 

h t tp ://www. usen ix. o rg/even ts/no98/ 
or telephone for the printed brochure 
1.714.588.8649. 

Sponsored by the USENIX Association 

USEUX 

Co-sponsored by: 

The FreeBSD Project mvw.freebsd.org 
Linux International www.li.org 
The OpenBSD Project www.openbsd.org 
The NetBSD Project www.net.bsd.org 
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2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
Phone: 510 528 8649 
FAX: 510 548 5738 
Email: <office@usenix.org> 


CONTRIBUTIONS SOLICITED 


WEB SITE 


http://www.usenix.org 


AUTOMATIC INFORMATION 


SERVER 

If you do not have access to the Web, 
finger <info@usenix.org> and you will be 
directed to the catalog which outlines ail 
conferences, activities, and services. 
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1998 Operational Key 
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You are encouraged to contribute articles, book revie> 
and announcements to ;login:. Send them via email tc 
<login@usenix.org> or through the postal system to l 
Association office. 


Send SAGE material to <tmd@usenix.org>. The 
Association reserves the right to edit submitted mater 
Any reproduction of this magazine in its entirety or ii 
part requires the permission of the Association and tl 
author(s). 

The closing dates for submissions to the next 
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